Détection de sniffers, what about mac OS??

Suite à mon billet sur la détection à distance de sniffers, je me suis mis à effectuer une série de test afin de tester l'efficacité de la méthode. J'ai pû rapidement constater qu'elle était redoutable envers les systèmes Windows (9x -> Vista) et Linux 2.4.x->2.6.x autant dire quasiment tous! Néanmoins, en raison de la convergeance vers moi des regards désaprobateurs des utilisateurs de MAC OS, se sentant oubliés, voici un petit billet sur la detection de sniffers tournant sous mac OS X.

Le test a été effectué en lançant tcpdump (l'installation de Wireshark a planté par un refus de l'installation de l'icone de l'application!!) sur un iBook G4.
Tant pis pour wireshark, tcpdump fait le même boulot, pas envie de chercher le problème...

Pour ceux qui seraient interessés, vous pouvez trouver wireshark pour mac ici, si vous avez le même problème que moi, installez les paquets à la main (par contre c'est super chiant un peu long) et lancez tcpdump dans un terminal.

J'ai relié le laptop à mon pc en ethernet (bien que le programme fonctionne aussi via le wifi, en point to point). Et là miracle (ou pas miracle en fait car MAC OS X est basé sur un kernel mach, il s'agit d'un système Unix, proche d'ailleurs des BSD), je pouvais détecter, à distance, si tcpdump était lancé ou non!

Petit copier/coller de la console, de deux essais, tcpdump étant lancé pour le premier et coupé pour le second. Pour ceux qui n'auraient pas lu le premier post de la série, une réponse de la cible à un paquet ARP transformé constitue une preuve que la machine est en mode promiscuous (capture de tous les paquets, même ceux qui ne lui sont pas destinés).

root@debianne:~/rsd# ./rsd -t 169.254.22.20 -i eth1
La cible 169.254.22.20 a repondu!
root@debianne:~/rsd# ./rsd -t 169.254.22.20 -i eth1
root@debianne:~/rsd#

Je commence à avoir fait le tour des principaux systèmes, et tous réagissent de la même manière à mes petits paquets ARP request bidouillés. Je pense qu'il va falloir se faire à l'idée que la méthode n'est pas trop mauvaise bien que basée sur un bug des noyaux. Si vous pouvez effectuer des tests sur des plateformes plus ou moins "exotiques" celà m'interresse grandement.

Portes dérobées nouvelle génération

Les Chevaux de Troie sont monnaie courante en ce moment et les analystes des sociétés de protection antivirale leur prédisent encore un bel avenir. Ces portes dérobées permettent à un pirate de conserver un accès sur une machine compromise, de la manipuler à distance, donc contrôler son contenu ou constituent des points d'entrée sur un réseau, permettant de compromettre d'autres machines.

Le modèle "classique" consiste à binder un serveur sur un port inutilisé, et à lui envoyer des commandes qu'il exécute. Evidemment, un simple nmap révèle la présence d'un tel programme et un firewall normalement configuré bloquera l'arrivée des commandes. Suivent alors les "reverse shells", qui se connectent aux pirates, là encore la parade est aisée à mettre en oeuvre (nmap et affinage des règles des firewalls si besoin).

Les portes dérobées "nouvelle génération" ont migrées là où à peu près personne ne les embête : dans les noyaux des sytèmes d'exploitation! Ces rootkits sont théoriquement indétectables (oui, je sais le débat fait rage...)

Sans aller jusqu'à coder en kernelspace, vous pouvez masquer un processus en écrivant dans argv[0], la chaine que vous y mettrez sera alors le nouveau nom du processus. Vous éliminez la menace ps -A (waw!)

Mais un autre facteur de furtivité est la manière de capturer les paquets contenant les commandes à exécuter. Un programme qui sniffe les paquets sans passer la carte en mode promiscuous, et qui n'écoute aucun port est indétectable par les outils actuels (à ma connaissance).

Le bypass des firewall peut se faire en envoyant les commandes à un service autorisé, et/ou en utilisant un smartspoofing si le contrôle est basé sur les adresses IP.

Pour peu que les commandes soient envoyées cryptées sur le réseau, la détection de la porte dérobée devient alors "mission très improbable"!!

Javascriptus delirium tremensis

Voilà ce qui fut pour moi une découverte hallucinante. Lors d'un passage sur l'excellent "Hacker webzine", je vis qu'il était possible d'accéder à la base de registres de Windows en JavaScript, via internet explorer. De plus, cet accès n'est pas limité (lecture à l'aide de la méthode RegRead, écriture avec RegWrite, effacement avec RegDelete). (source : http://www.0x000000.com/index.php?i=443)

L'auteur présente un exemple de code permettant de désactiver le filtre anti-phishing de Internet Explorer, mais imaginez la puissance de la chose!
En surfant avec IE (personne ne vous y oblige non plus hein...) vous hurlez à tous les sites visités votre clef d'activation Windows ou le path vers votre carnet d'adresses.

Mes tests sous IE_7 montrent que ce dernier détecte tout de même un "contenu actif" et demande confirmation de l'exécution à l'utilisateur.
D'un autre côté, pour naviguer en toute sécurité il faudrait se limiter à la lecture de contenus passifs, sans images etc... Hmmmm je vais continuer ma prise "insensée" de risques via Opera ou Firefox, selon l'humeur! Passer d'un web 2.0 à un web 0.2 n'est pas pour me ravir!