dsniff Foire Aux Questions <author>version originale par Dug Song <<htmlurl url="mailto:dugsong@monkey.org" name="dugsong@monkey.org">> &nl; traduction française par Denis Ducamp <Denis.Ducamp@groar.org> <date>21 juin 2001 / 30 juin 2001 <toc> <figure loc=""> <eps file=""> <IMG SRC="monkey6.gif"> <caption></caption> </figure> <sect>Général <sect1>Qu'est-ce que dsniff ? dsniff est une collection d'outils pour auditer un réseau et effectuer des tests d'intrusion. dsniff, filesnarf, mailsnarf, urlsnarf, et webspy se mettent passivement à l'écoute d'un réseau pour les données intéressantes (mots de passe, e-mails, fichiers, etc.). arpspoof, dnsspoof, et macoff facilitent l'interception du trafic réseau normalement non accessible à un attaquant (e.g, dû à un commutateur de niveau 2). sshmitm et webmitm mettent en oeuvre des attaques actives du singe intercepteur (ndt : Dug Song utilisant l'expression "monkey-in-the-middle" à la place de "man-in-the-middle", j'utiliserai donc l'expression "les attaques du singe intercepteur" plutôt que "les attaques de l'intercepteur") contre des sessions SSH et HTTPS redirigées en exploitant des liens faibles dans les PKI ad-hoc. <sect1>Pourquoi le publiez-vous ? Sans de fortes motivations pour changer, les protocoles réseaux peu sécurisés et leurs mises en oeuvre restent souvent incorrigés, laissant beaucoup de l'Internet vulnérable aux attaques dont les communautés de recherche ont prévenu depuis des années (e.g. interceptions de clés privées SSH / PGP et fichiers .Xauthority via NFS, écoutes dans un environnement commuté, exploitations de relations de confiance basées sur le DNS, attaques du singe intercepteur contre SSH et HTTPS, etc.). En même temps, les législations en suspend tel que UCITA, European Draft Cybercrime Treaty, et DMCA menacent de rendre criminelles les recherches en sécurité qui exposent les faiblesses dans la conception et la mise en oeuvre de systèmes distribués. En publiant dsniff tant que cela est toujours légal alors, les administrateurs, les ingénieurs réseau, et ceux exerçant la sécurité informatique seront mieux équipés avec les outils pour auditer leurs propres réseaux avec que cette connaissance devienne secrète. <sect1>Quelles plates-formes sont supportées ? Seulement trois plates-formes me sont accessibles pour tester: OpenBSD (i386), RedHat Linux (i386), et Solaris (sparc). D'autres ont reporté des succès sur FreeBSD, Linux Debian, Linux Slackware, AIX et HP-UX. Un portage Windows d'une version plus ancienne est accessible depuis <htmlurl url="http://www.datanerds.net/~mike/dsniff.html" name="http://www.datanerds.net/~mike/dsniff.html">, et un port MacOS X est à ce qu'on dit en préparation. <sect1>Quoi d'autre est requis ? Le package dsniff repose sur plusieurs packages additionnels tiers : <itemize> <item><htmlurl url="http://www.sleepycat.com/" name="Berkeley DB"> <item><htmlurl url="http://www.openssl.org/" name="OpenSSL"> <item><htmlurl url="http://www.tcpdump.org/" name="libpcap"> <item><htmlurl url="http://www.packetfactory.net/Projects/Libnet" name="libnet"> <item><htmlurl url="http://www.packetfactory.net/Projects/Libnids" name="libnids"> </itemize> OpenBSD a déjà intégré les trois premiers packages dans le système de base, ne laissant seulement que libnet et libnids comme dépendances additionnelles (voir /usr/ports/net/{libnet,libnids} ou le site FTP de OpenBSD pour les packages binaires). Linux, Solaris, et la plupart des autres OS requièrent tout d'abord la construction de tous les packages tiers (incluant RedHat, qui est livrée avec une libpcap non standard) (voir <htmlurl url="http://www.rpmfind.net/" name="rpmfind.net"> pour les RPM binaires, que vous devrez toujours vérifier avec rpm --checksig). Ce logiciel nécessite une compréhension minimale de la sécurité réseau pour une utilisation rationnelle. Je n'admettrai pas d'aussi démentes questions que "Puis-je utiliser cela pour espionner les sessions de discussion de ma femme ?", ni je ne m'ennuyerai à expliquer les mécanismes derrière chaque exploitation. RTFM (lisez le manuel), et RTFS (lisez les sources). <sect1>Il y a-t-il une mailing liste ? Une mailing liste pour les annonces de dsniff et des discussions modérées est accessible. Envoyez un message avec le mot "subscribe" dans le corps du message à <htmlurl url="mailto:dsniff-request@monkey.org" name="dsniff-request@monkey.org">. Aucune archive de cette liste est déjà accessible. <sect>Installation <sect1>Ou puis-je trouver des packages RPM de dsniff ? Voyez le site de distribution de packages RPM de Henri Gomez <htmlurl url="mailto:hgomez@slib.fr" name ="hgomez@slib.fr"> à <htmlurl url="http://www.falsehope.com/ftp-site/home/gomez/dsniff/" name="http://www.falsehope.com/ftp-site/home/gomez/dsniff/"> ou essayez <htmlurl url="http://www.rpmfind.net/" name="rpmfind.net"> pour des packages RPM tiers. Des packages debian sont également disponibles, voir <htmlurl url="http://packages.debian.org/unstable/net/dsniff.html" name="http://packages.debian.org/unstable/net/dsniff.html">. <sect1>Ou puis-je trouver des packages dsniff pour Solaris ? Voyez <htmlurl url="http://www.sunfreeware.com/programlistsparc8.html#dsniff" name="sunfreeware.com"> pour les packages Solaris 8. <sect1>Dois-je réellement installer tous ces packages tiers ? Non, le script configure de dsniff va accepter un répertoire de compilation comme argument de ses différentes options --with-libxxx . Compilez tous les packages tiers d'abord, avant d'exécuter le script configure de dsniff. <sect1>Make s'arrête avec "missing R_NOOVERWRITE and R_NEXT declarations" ? Voyez la question suivante. J'obtiens le plus ceci des utilisateurs de Linux, spécialement de ceux utilisant Mandrake, pour quelque raison. <sect1>Make s'arrête avec "undefined symbol dbopen or __db185_open" ? Soyez sûr de compiler Berkeley DB avec ./configure --enable-compat185 . <sect1>Configure ne trouve pas Berkeley DB, même s'il est installé ! dsniff-2.2 avait un script configure cassé qui refusait de trouver n'importe quel Berkeley DB installé. Pointez plutôt ./configure --with-db vers votre répertoire de compilation de Berkeley DB, ou mettez à jour vers dsniff-2.3 . <sect1>Make s'arrête avec "undefined reference to pcap_open_live_new" ? Vous avez probablement lié une version différente de libpcap que celle utilisée pour compiler libnids (c'est souvent reporté par des utilisateurs Linux qui ont installé libnids depuis un package RPM). Soyez sûr de compiler libnids et dsniff avec la même distribution de libpcap. <sect1>Make s'arrête avec "undefined reference to RAND_status" ? Mettez à jour votre installation de OpenSSL. <sect>Fonctionnement <sect1>Comment écouter dans un environnement commuté ? Le meilleur itinéraire est de simplement se faire passer pour la passerelle par défaut, volant le trafic client à destination de quelque destination distante. Bien sûr, le trafic doit être réexpédié par votre système attaquant, soit en activant l' "IP forwarding" dans le noyau (sysctl -w net.inet.ip.forwarding=1 sous BSD) soit avec un programme en espace utilisateur qui accomplit la même chose (fragrouter -B1). Plusieurs personnes ont reporté avoir détruit la connectivité sur leur LAN vers l'extérieur en "arpspoofant" la passerelle, et en oubliant d'activer l' "IP forwarding" sur le système attaquant. Ne faites pas cela. Vous avez été prévenus. <sect1>arpspoof échoue toujours avec "couldn't arp for host" ? Vous pouvez seulement "arpspoofer" les système sur le même sous réseau que votre système attaquant. <sect1>Pourquoi dsniff / *snarf ne voient-ils rien ? <sect2>...quand arpspoof est utilisé pour intercepter le trafic client ? Soyez sûrs que vous êtes actuellement en train de réexpédier les paquets interceptés, soit via l' "IP forwarding" du noyau soit avec fragrouter. Si vous voyez en effet la moitié cliente de la connexion TCP (e.g. comme vérifié en utilisant tcpdump), soyez sûrs que vous avez activé le réassemblage de flux TCP en half-duplex de dsniff (dsniff -c). Les outils *snarf ne supportent pas encore ce mode de fonctionnement. <sect2>...quand je peux voir avec tcpdump les connexions qui continuent ? libnids, la librairie de réassemblage TCP/IP sous-jacente de dsniff, a besoin de voir le début d'une connexion afin de la suivre. Il y a plusieurs bonnes raisons pour cela, comme décrit dans l'article précurseur de Ptacek et Newsham sur l'évasion des IDS réseaux. La meilleure chose à faire, dans un scénario dynamique de test d'intrusion, est de : <enum> <item>commencer à renifler <item>réinitialiser sélectivement les connexions existantes avec tcpkill, et alors <item>d'attendre que les utilisateurs se reconnectent </enum> C'est horriblement intrusif et mauvais, mais d'autre part, les tests d'intrusion sont ainsi. :-) <sect2>...quand j'écoute un réseau occupé, ou un port d'écoute d'un commutateur ? Vous devez perdre quelques paquets, soit au port d'écoute du commutateur (recopier 10 ports Ethernet à 100 Mbit vers un seul port n'est jamais une bonne idée) soit dans libpcap - jetant l'anathème sur libnids, qui a besoin de voir tous les paquets d'une connexion pour un réassemblage strict. Essayez plutôt de réactiver le réassemblage de flux TCP en "half-duplex" (dsniff -c) le mieux de dsniff. D'autres améliorations générales des performances de dsniff incluent : <enum> <item>SMP, qui sur la plupart des OS résulte dans un seul processus traitant l'importante charge d'interruptions, permettant à l'autre de faire le travail réel <item>de bonnes cartes réseau et pilotes avec des DMA qui fonctionnent. <item>de larges tampons dans le noyau pour une capture de paquets efficace (les BPF d'OpenBSD font déjà cela) <item>un support noyau particulier pour une capture de paquets en une seule copie (e.g. un accès direct à de tels tampons dans kmem depuis l'espace utilisateur) </enum> <sect2>...quand j'écoute le trafic sur un port inhabituel ? Essayez d'activer l'option magique de dsniff (dsniff -m) de détection automatique de protocole, qui devrait détecter le protocole approprié (si dsniff le connaît) fonctionnant sur n'importe quel port. Si dsniff échoue toujours à sélectionner le trafic, ce peut être un protocole inhabituel que dsniff ne supporte pas encore. Créez un fichier services de dsniff ainsi <verb>hex 12345/tcp</verb> où 12345 est le port TCP du service inconnu, exécutez dsniff avec -f services et envoyez moi la sauvegarde hexadécimale résultant de la trace de la connexion. Quelques protocoles propriétaires sont modifiés quasiment journalièrement, ce n'est pas facile de rester à jour ! <sect2>...quand j'écoute un trafic inconnu, ou une nouvelle version de certains protocoles ? Les routines de décodage de dsniff sont admises comme étant plutôt dégueulasses, et empruntant de nombreux raccourcis pour le bien des performances (et de la simplicité - essayez de décomposer entièrement la trentaine de protocoles ouverts / propriétaires que dsniff supporte!). De plus, beaucoup des protocoles que dsniff traite sont complètement propriétaires, et requièrent du reverse engineering qui peut ne pas être complet du tout ou fidèle en face de nouvelles versions ou extensions de protocoles. La meilleure façon d'obtenir de nouveaux protocoles supportés par dsniff est de m'envoyer des traces de trafic de quelques connexions / sessions complètes, depuis le début jusqu'à la fin (en soyant sûrs de capturer les paquets dans leurs intégralités avec tcpdump -s 4096, ou avec <htmlurl url="http://ethereal.zing.org/" name="Ethereal">), accompagné de tout pointeur vers de la documentation pertinente (ou des implémentations client / serveur). Si vous voulez vous y essayer, ajoutez une entrée au fichier dsniff.services de dsniff en faisant correspondre le trafic que vous souhaitez analyser avec la routine de décodage "hex", et disséquez les sauvegardes hexadécimales manuellement. <sect1>Comment puis-je écouter / détourner les connexions HTTPS / SSH ? Bien que HTTPS et SSH soient chiffrés, ils font tous les deux confiance aux faibles liens des certificats à clés publiques pour identifier les serveurs et établir des contextes de sécurité pour chiffrement symétrique. Comme la vaste majorité des utilisateurs n'arrive pas à comprendre la gestion obtuse de la confiance digitale que les PKI présentent (e.g. est-ce qu'un DN X.509v3 est réellement significatif pour vous ?), une simple attaque du singe intercepteur fonctionne assez bien en pratique. Le trafic client vers un serveur cible peut être intercepté en utilisant dnsspoof et relayé à sa destination initiale en utilisant les relais sshmitm et webmitm (qui arrivent également à capturer les mots de passe en transit). Par exemple, pour écouter les mots de passe de la messagerie par web Hotmail, créer un fichier hosts pour dnsspoof tel que : <verb>1.2.3.4 *.passport.com 1.2.3.4 *.hotmail.com </verb> où 1.2.3.4 est l'adresse IP de votre système attaquant. Les clients locaux tentant de se connecter à Hotmail vont à la place être renvoyés vers votre machine, où webmitm va se présenter à eux avec un certificat auto signé (avec le nom distinctif X.509v3 approprié), et relayera leurs trafics écoutés au site réel Hotmail. sshmitm est peut être plus efficace dans les salles de terminaux des conférences ou dans les webcafés puisque la plupart des utilisateurs mobiles de SSH n'emportent pas avec eux les empreintes des clés de leurs serveurs (seulement présentées par le client OpenSSH, de toutes façons). Même les utilisateurs avancés de SSH qui insistent sur les mots de passe à usage unique (e.g. S/Key), l'authentification RSA, etc. constituent toujours un risque, puisque sshmitm supporte l'écoute et le détournement de sessions interactives avec son option -I . <sect1>Pourquoi dsniff ne capture pas les authentifications Oracle ? Augmentez la valeur de snaplen (ndt : la longueur des captures) par défaut avec dsniff -s 4096. Les authentifications Oracle peuvent être assez bavardes... <sect1>Pourquoi webmitm rapporte "openssl: not found" ? webmitm utilise l'exécutable openssl pour générer les certificats. Soyez sûrs que l'exécutable openssl (généralement dans /usr/local/ssl/bin/ sur la plupart des systèmes) est dans votre PATH (ndt : votre chemin de recherche). <sect1>Pourquoi dsniff se plante avec "Bus Error (core dumped)" ? Il y a des chances, que vous ayez compilé avec une version instable de libnids (libnids-1.14 sur Solaris en particulier). Mettez à jour vers la dernière version de <htmlurl url="http://www.packetfactory.net/Projects/Libnids/" name="http://www.packetfactory.net/Projects/Libnids/">, et si vous avez toujours des problèmes, recompilez tout avec l'option -g et envoyez moi le "stack backtrace" (ndt : le contenu de la pile). <sect1>Pourquoi j'obtiens "Socket type not supported" sur mon système Linux Cobalt ? De Brian Costello (<htmlurl url="http://www.mksecure.com/" name="http://www.mksecure.com/">) : vous devez compiler votre noyau pour inclure une "Packet Socket" - dans "Networking Options" dans la configuration de votre noyau Linux, dites "YES" à "Packet Socket". Si vous avez un noyau 2.3/2.4, vous devriez probablement dire "yes" à "mmapped I/O", puisque cela offre des performances supérieures. De Simon Taylor (<htmlurl url="mailto:simon@band-x.net" name="simon@band-x.net">) : C'est actuellement déjà dans le noyau, en tant que module : /sbin/insmod af_packet . <sect1>Mon système Linux 2.2 - 2.4 se plante / la carte réseau s'arrête de répondre quand j'utilise vos outils ! Consultez votre bazar Linux local pour conseil. ;-) Peut être avez vous compilé un noyau instable ? <sect>Contre mesures <sect1>Comment est-ce que je détecte dsniff sur mon réseau ? Au niveau 2 : arpwatch de LBL peut détecter les changements dans les correspondances ARP sur le réseau local, tels que ceux causés par arpspoof et macof. Au niveau 3 : un renifleur programmable tel que NFR peut regarder soit les anomalies réseau évidentes soit les effets secondaires de certaines attaques actives de dsniff, tels que : <itemize> <item>les paquets "ICMP port unreachable" vers le serveur DNS local, un résultat de la victoire de dnsspoof gagnant la course en répondant à une requête DNS cliente avec des données forgées <item>trop de paquets "out-of-window TCP RST" ou des inondations de paquets ACK causés par tcpkill et tcpnice </itemize> Les outils d'écoute passive de dsniff peuvent être détectés avec antisniff de l0pht, s'il est utilisé régulièrement pour mesurer la latence du réseau (et si vous pouvez supporter la flagrante charge qu'il génère). Les techniques de réseaux de pots de miel pour la détection de renifleurs (tel que le détecteur de renifleurs à IBM Zurich GSAL) présentent également d'intéressantes contre mesures de dernier recours... <sect1>Comment est-ce que je protège mon réseau contre dsniff ? Au niveau 2 : activer la sécurité au niveau des ports des commutateurs ou imposer des entrées ARP statiques pour certains systèmes aide à protéger contre les redirections d'arpspoof, même si ces deux contre mesures sont extrêmement inconvénientes. Au niveau 3 : IPSEC couplé aux services de noms authentifiés et sécurisés (DNSSEC) peut prévenir les redirections de dnsspoof et les écoutes passives triviales. Malheureusement, l'IKE d'IPSEC est un protocole d'échange de clés prétentieux conçu par un comité, donc exercer et préserver un déploiement universel au travers de l'Internet est quasiment impensable dans un futur immédiat. Au niveau 4 : ne pas autoriser les protocoles applicatifs peu sécurisés et propriétaires ou les protocoles à mots de passe en clair sur votre réseau. dsniff est utile dans l'aide à la détection de telles violations de politiques, particulièrement quand il est utilisé dans le mode magique (dsniff -m) de détection automatique de protocole. C'est largement un problème de correction de l'éducation des utilisateurs peut être mieux laissé aux BOFH (ndt : Bastard Operator From Hell) expérimentés. :-) L'authentification réseau tierce forte et de confiance (telle que Kerberos) n'est généralement pas sujet au genre d'attaques triviales du singe intercepteur qui embête les PKI dans de tels ad-hoc déploiements comme SSH et HTTPS. Mettant en avant un service de noms authentifié comme DNSSEC pour une distribution sécurisée de clés comme une solution, même si réalistement plusieurs années nous séparent d'un déploiement universel. Une mesure intérimaire raisonnable est d'avoir les utilisateurs activant l'option StrictHostKeyChecking de SSH, et de distribuer les signatures des clés des serveurs aux clients mobiles. Note : Kerberos a ses propres problèmes, quoique - voir <htmlurl url="http://www.monkey.org/~dugsong/kdcspoof.tar.gz" name="kdcspook">, et mon <htmlurl url="http://www.monkey.org/~dugsong/john-1.6.krb4.patch-3" name="patche AFS/Kerberos"> pour <htmlurl url="http://www.openwall.com/john/" name="John the Ripper">. Les firewalls peuvent être un bénissement mitigé - pendant qu'ils protègent les réseaux privés sensibles de l'Internet public et de non confiance, ils tendent également à encourager un modèle de sécurité réseau au périmètre "strict à l'extérieur, relâché à l'intérieur". dsniff a peut-être eu plus d'effets derrière les firewalls, où Telnet, FTP, POP, et autres protocoles à mots de passe en clair sont librement utilisés, non entravés par la politique de sécurité de la société. <sect>Références <sect1>Où puis-je en apprendre plus à propos de ces attaques ? Beaucoup des attaques mises en oeuvre dans dsniff sont assez anciennes, bien que toujours efficaces dans la plupart des environnements. Clairement, nous avons toujours un long chemin à parcourir pour sécuriser nos réseaux... <enum> <item>S. Bellovin. "<htmlurl url="http://www.research.att.com/~smb/papers/dnshack.ps" name="Using the Domain Name System for System Break-Ins">". Proceedings of the 5th Usenix UNIX Security Symposium, June 1995. <item>M. Blaze. "<htmlurl url="http://citeseer.nj.nec.com/pdf/339550" name="NFS Tracing by Passive Monitoring">". Proceedings of the Winter USENIX Conference, January 1992. <item>C. Ellison. "<htmlurl url="http://world.std.com/~cme/usenix.ps" name="Establishing Identity Without Certification Authorities">". Proceedings of the 6th USENIX Security Symposium, July 1996. <item>E. Felten, D. Balfanz, D. Dean, D. Wallach. "<htmlurl url="http://www.cs.princeton.edu/sip/pub/spoofing.ps" name="Web Spoofing: An Internet Con Game">". 20th National Information Systems Security Conference, October 1997. <item>D. Farmer, W. Venema. "<htmlurl url="http://www.porcupine.org/satan/admin-guide-to-cracking.html" name="Improving the Security of Your Site by Breaking Into it">". December 1993. <item>U. Flegel. "<htmlurl url="http://rootshell.connectnet.com/docs/ssh-x11.ps.gz" name="The Interaction Between SSH and X11">". September 1997. <item>T. Ptacek, T. Newsham. "<htmlurl url="http://www.securityfocus.com/data/library/ids.ps" name="Insertion, Evasion, and Denial of Service: Eluding Network Intrusion Detection">". Secure Networks, Inc., January 1998. </enum> <htmlurl url="http://naughty.monkey.org/~dugsong/" name="Dug Song"> <<htmlurl url="mailto:dugsong@monkey.org" name="dugsong@monkey.org">> </article>