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!

Canaux d'évasion

Nul rapport ici avec une quelconque structure mafieuse chargée d'aider des belges à fuir en Roumanie via le mexique. Non, non, tout simplement une approche de la stéganographie sur les flux.

Explications: la stéganographie (suite à un projet entammé en cours vous risquez d'en entendre parler...) désigne l'ensemble des techniques de dissimulation d'information. Contrairement à la cryptographie, qui ne cherche qu'à rendre le message incompréhensible, la stéganographie sert à le rendre assez anodin pour que l'on ne soupçonne même pas sa présence.
Ainsi, une des techniques les plus célèbres consiste à cacher des données dans une image en utilisant uniquement les bits de poids faible de cette dernière. La différence entre l'image modifiée et l'image originale n'étant pas visible à l'oeil nu. Ceci constitue une approche de type "dissimulation de stocks", le message étant un bloc avant et après application du procédé.

Cet article traite lui de la dissimulation de flux (on y arrive!). Fixons nous pour objectif d'évader un flux d'un réseau "protégé" (ou plus simplement : envvoyer des informations depuis une machine du réseau vers l'extérieur de la façon la plus discrète possible). Une condition sine qua non porte sur l'intensité du flux. Plus celui-ci est petit, plus il sera aisé de l'évader.

L'idée (lue dans le magasine MISC n°18) consiste à envoyer ces données en imitant des connections anodines, les moins surveillées possible (on oubliera donc http, souvent filtré) et standart.

Un cheval de troie utilise des paquets ICMP, donc ce protocol est de plus en plus bloqué, même provenant du réseau, par les firewalls.
Un bon protocole est le DNS. Les connections vers les port 53 sont souvent autorisées par négligence/peur des disfonctionnements. De plus, un simple utilisateur peut envoyer des paquets UDP sur le réseau, et enfin, des requêtes DNS, même répétées, n'attirent pas trop l'attention sur une grosse infrastructure.

Il est néanmoins important d'effectuer au minimum un petit décalage, base64_encode ou xor sur les données s'il s'agit de texte, afin qu'elles ne soient pas lisibles directement dans un sniffer.

De tels flux peuvent être très difficiles à détecter, suivre et analyser, nottament s'ils "rebondissent" sur plusieurs machines. Attention tout de même à ne pas pécher par excès de zèle, tout doit rester discret! Que l'on traite des flux ou des stocks, les concepts de base de la stéganographie restent les mêmes.

Je suis actuellement à la recherche d'autres idées concernant la mise en place de réseaux furtifs (et pas uniquement cryptés). Le sujet est vaste. N'hésitez pas à me soumettre d'autres idées.

Voici un projet hébergé sur Savannah, et proposant du DNS tunelling. Ce projet est relativement originale et intéressant : NSTX

Danger, "browser based application"!

Cet après midi, il m'a été donné l'occasion de tester quelque chose de "nouveau". Je me suis rendu dans une bibliothèque (non, la nouveauté n'est pas là) et suis tombé sur une très jolie interface de recherche dans la base de donnée. Pris d'un réflexe quasi-compulsif, ma première recherche fut:

"><script>alert("Hello");</script><"

Quelle ne fut pas ma surprise de voir alors l'ordinateur me saluer! L'application de recherche était, comme l'indiquait l'AlertBox, exécutée au sein d'Internet Explorer.

Or cet ordinateur était complètement "restreint", j'entends par là que tout avait été fait pour que ne soient effectuées dessus QUE des recherches dans la base de données. Pourtant, je me retrouvais à pouvoir naviguer sur le web (via une iframe)

"><iframe src="http://www.google.fr" width=100%
      height=100%><"

Je continuerais peut être l'exploration si l'occasion se présente, mais je ne serais pas étonné que l'application soit exécutée en utilisateur Administrateur et sans options de sécurité particulières.

Tout cet article non pas pour inciter au piratage des bibliothèques mais plutôt pour attirer l'attention sur l'importance que peut prendre une toute petite faille XSS lorsque le contexte s'y prête. Une telle implémentation d'un moteur de recherche dans une base locale est un choix contestable.
Pourquoi faire s'exécuter le client dans Internet Explorer? Utiliser un navigateur web comme base pour un système ne devant pas se connecter au web est clairement une erreur bien plus grossière que l'oubli de filtrer les html_entities!

Detection de sniffers par méthode DNS

Toujours dans la détection à distance de sniffers, voici une méthode, implémentée dans le logiciel Antisniff, et qui m'a paru relativement intéressante.
Antisniff est un soft multiplateforme conçu par L0pht Heavy Industry (Un groupe d'experts sécurité de Boston, auteurs du célèbrissime L0phtcrack entre autre).

En plus de détecter la présence d'un sniffer, elle peut permettre de déterminer si celui-ci a été installé dans un but malveillant.
En effet, beaucoup de sniffers "pirates" effectuent des requêtes de résolution DNS inversées (ils ont l'IP dans les paquets, ils veulent connaitre le nom de la machine) afin de cartographier le réseau et trouver des machines "intéressantes" partant du principe que beaucoup de machines sont identifiées par le service qu'elles hébergent (serveur de mail, de fichier, Desktop admin etc...).

Antisniff exploite donc cette propriété en envoyant des paquets sur le réseau (non-switché) à des machines fictives et place la carte en mode promiscuous. Si il perçoit une demande de résolution DNS inverse à propos de ces machines fictives, ce peut être qu'un sniffer soit installé sur l'émetteur de la requête DNS!

Sniffers remote detection

Bien que les sniffers soient des outils d'administration et de dévelopement terriblement utiles, leur mise en place sur un réseau par des utilisateurs malveillants peut leur permettre de corrompre peu à peu toutes les machines du réseau.

Ils peuvent être plus ou moins furtifs, mais la quasi-totalité fonctionnent en plaçant la carte réseau en mode promiscuous. C'est à dire en mode d'acceptation de tous les paquets qui se présentent à elle, qu'ils lui soient déstinés ou non.
Ce peut être extrêmement difficile à détecter sur de gros réseaux si l'on n'y prend garde, mais de là à penser que c'est mission impossible il y a un pas que nous n'allons pas franchir!

Sur une machine, un simple ipconfig permettra de constater si la carte est ou non en mode promiscuous.
Mais le problème est différent lorsque la détection doit se faire à distance, et c'est pourtant une nécessité sur de gros réseaux.
Plusieurs approches sont possibles, mais l'une a retenu mon attention, elle est basée sur l'envoi de requêtes ARP.

D'ordinaire, ces requêtes sont envoyées en broadcast (adresse MAC FF:FF:FF:FF:FF:FF). Mais si on modifie le champs "destination" en y mettant FF:FF:FF:FF:FF:FE , une machine en mode "normal" refusera le paquet, mais pas une hébergeant un sniffer.
Passé la barrière matérielle, le paquet sera envoyé au noyau. Nous nous retrouvons alors face à une barrière logicielle. Mais il y a un bug sur les noyaux Linux 2.2->2.6 et Windows 95->Vista (vérifié pour linux 2.4 et 2.6, windows XP et Vista). Les adresses de destination ne sont pas complètement analysées, et pour le kernel, FF:FF:FF:FF:FF:FE sera identique à FF:FF:FF:FF:FF:FF. L'ordinateur nous enverra donc un paquet de type ARP reply.

Il suffit alors, après l'envoi du paquet d'attendre une réponse et d'analyser les champs de cette réponse pour connaitre l'émetteur et en déduire que sa carte réseau est en mode promiscuous.
Je suis actellement en train d'écrire un logiciel exemple. Je posterais le code ici lorsqu'il sera fini.

Update : Voici une première version fonctionnelle du code (archive zip, archive tar.gz), toute fraichement sortie de vim. Il doit y avoir pas mal de choses à revoir et optimiser. Je tacherais de trouver le temps nécessaire dans les semaines à venir.
En attendant le code constitue un bon (j'espère) exemple d'utilisation des raw sockets.