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!