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.
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.
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 http://www.datanerds.net/~mike/dsniff.html, et un port MacOS X est à ce qu'on dit en préparation.
Le package dsniff repose sur plusieurs packages additionnels tiers :
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 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).
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 à dsniff-request@monkey.org. Aucune archive de cette liste est déjà accessible.
Voyez le site de distribution de packages RPM de Henri Gomez hgomez@slib.fr à http://www.falsehope.com/ftp-site/home/gomez/dsniff/ ou essayez rpmfind.net pour des packages RPM tiers. Des packages debian sont également disponibles, voir http://packages.debian.org/unstable/net/dsniff.html.
Voyez sunfreeware.com pour les packages Solaris 8.
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.
Voyez la question suivante. J'obtiens le plus ceci des utilisateurs de Linux, spécialement de ceux utilisant Mandrake, pour quelque raison.
Soyez sûr de compiler Berkeley DB avec ./configure --enable-compat185 .
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 .
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.
Mettez à jour votre installation de OpenSSL.
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.
Vous pouvez seulement "arpspoofer" les système sur le même sous réseau que votre système attaquant.
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.
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 :
C'est horriblement intrusif et mauvais, mais d'autre part, les tests d'intrusion sont ainsi. :-)
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 :
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
hex 12345/tcp
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 !
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 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.
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 :
1.2.3.4 *.passport.com 1.2.3.4 *.hotmail.com
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 .
Augmentez la valeur de snaplen (ndt : la longueur des captures) par défaut avec dsniff -s 4096. Les authentifications Oracle peuvent être assez bavardes...
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).
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 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).
De Brian Costello ( 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 ( simon@band-x.net) : C'est actuellement déjà dans le noyau, en tant que module : /sbin/insmod af_packet .
Consultez votre bazar Linux local pour conseil. ;-)
Peut être avez vous compilé un noyau instable ?
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 :
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...
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 kdcspook, et mon patche AFS/Kerberos pour 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é.
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...
Dug Song < dugsong@monkey.org>