Anonymisation de connexions TCP grâce à TOR
Alors, je suis anonyme ?
Précautions supplémentaires
Comme je l'ai souligné à de nombreuses reprises, TOR se limite à l'anonymisation de la connexion TCP en elle-même, plus précisément à la dissimulation de l'adresse source (voire destination dans le cas des services cachés). Cela implique que certains aspects qui révèlent les intentions - ou à plus forte raison l'identité - de l'utilisateur ne sont pas traités par celui-ci.
Requêtes DNS
Parmis les aspects non traités par TOR, on peut noter les requêtes DNS. En effet, si l'on prend l'exemple de Firefox, celui-ci n'effectue pas par défaut les requêtes DNS en passant par le proxy SOCKS configuré. Cela se traduit par des requêtes effectuées en clair, révélant les sites consultés. Ce problème spécifique peut être configuré dans Firefox. Il suffit de se rendre dans la fenêtre d'édition avancée des propriétés, et d'y configurant la valeur network.proxy.socks_remote_dns, en la modifiant à true. Ceci forcera les requêtes DNS à être effectuées en passant par le proxy SOCKS configuré (l'OP de TOR bien sûr).
HTTP, cookies et données personnelles
Un autre aspect pouvant révéler l'identité de l'utilisateur concerne le protocole HTTP et les cookies que la norme définit. Ces cookies sont par définition une mémorisation d'une caractéristique de l'utilisateur pour le site visité. Un exemple de l'utilisation de cookies est celui des sessions qui sont mémorisées même à la fermeture du navigateur, comme celle de www.google.com lorsqu'on a un compte Google. Si l'on ne prend pas soin d'inhiber ces cookies, l'adresse IP de la station utilisée sera effectivement masquée, mais Google sera toujours au courant de l'identité de la personne associée au compte Google. Une solution, recommandée par les auteurs de TOR, est d'utiliser un proxy HTTP du nom de Privoxy dont la particularité est de fournir cet anonymat que TOR ne couvre pas.
Renforcer l'anonymat en étant soi-même un OR
Enfin, une autre faiblesse concernant l'anonymat de l'utilisateur repose sur le fonctionnement de TOR. Que se passe-t'il dans le cas où le premier OR est compromis, qu'il est factice, tenu par un attaquant ? Il est par exemple capable d'observer les réponses relayées du noeud de sortie vers l'OP, puisqu'il est en possession de la dernière clé utilisée pour chiffrer les données de la cellule. Une solution est alors de faire tourner un serveur TOR local : il n'est alors plus possible de déterminer si les connexions faites vers l'extérieur sont des connexions dont la finalité est un besoin de l'utilisateur, ou bien la création d'un circuit dont le serveur de l'utilisateur ferait partie.
Attaques possibles
Beaucoup d'attaques sont possibles et ont été documentées sur TOR. Mais c'est le cas de la plupart des protocoles introduisant des notions de sécurité. Je ne peux pas ici expliquer leur fonctionnement en détail, ou comment TOR s'en protège, car c'est un sujet très vaste. Mais je vais en citer quelques unes, qui permettront, j'espère, d'éveiller votre curiosité de lecteur et de prendre conscience que la sûreté de l'anonymat n'est garantie qu'en l'absence d'attaquants.
- Attaques passives qui ne nécessite pas de la part de l'attaquant d'effectuer des actions directement
- Observation : en observant les tendances, les patterns d'utilisation du réseau, un attaquant peut être capable d'identifier le type de trafic sans en connaître son contenu. Ce genre d'attaque se complique lors de l'utilisation de plusieurs types de service simultanée
- Corrélation de timing de bout en bout : TOR n'empêche pas ce genre d'attaque. Un attaqueur global pourrait littéralement observer les allers et venus des données et en déduire quel noeud communique avec quel serveur
- Attaques actives
- Attaques de "marquage" : un OR hostile pourrait altérer les données contenues dans les cellules. Une requête HTML deviendrait alors une bouillie de données sans aucun sens niveau HTML. Ce genre d'attaque est rendu impossible par le contrôle d'intégrité implémenté dans les cellules
- Faire tourner un OR hostile : il peut d'abord être un observateur du trafic passant par celui-ci, ou encore créer des circuits vers lui-même, ou modifier le trafic qu'il est censé router. Dans tous les cas, il doit être à l'une des extrémités du circuit pour pouvoir compromettre l'anonymat de l'utilisateur
- Attaques sur le service d’annuaires
- Corrompre un Directory Server : en corrompant l'annuaire d'un Directory Server, un attaquant peut interférer dans l'annuaire final utilisé par les OPs. Cependant l'inclusion/exclusion d'un OR dans l'annuaire étant évaluée à la majorité, cette attaque est rendue obsolète, sauf dans le cas d'une majorité de Directory Server corrompue
- Détruire des Directory Servers) : si quelques Directory Servers sont incapacités, les OPs seront toujours capables de trouver des ORs grâce au système de concensus. Si plus de la moitié sont détruits, alors une intervention manuelle de l'utilisateur sera requise pour valider les ORs puisque le système du concensus ne sera plus utilisable
- Attaques contre les points de rendez-vous
- Flood de requêtes d’introduction : un attaquant pourrait flooder les points d'introduction d'un service caché. Mais TOR permet l'utilisation de jeton d'autorisations, qui permettrait de bloquer les requêtes au niveau des points d'introduction
- Compromettre un point d’introduction : un attaquant contrôlant un point d'introduction d'un service peut flooder le service, ou intercepter des requêtes vers ce service. Le flooding peut être détecter, le circuit incriminé sera alors fermé par le noeud du service. Cependant afin de s'assurer que ses points d'introduction ne bloquent pas les requêtes, le service caché (son administrateur) devrait effectivement des requêtes à ses points de rendez-vous périodiquement afin de s'assurer qu'elles lui parviennt bien
Hack of the year 2007
Les faits
En novembre 2007, un pirate suédois nommé Dan Erstad divulgue de nombreux mots de passe appartenant à de nombreuses ambassades, ministères et agences gouvernementales.
Dan Erstad devient rapidement une célébrité sur le net. Tout le monde s'interroge sur ce piratage spectaculaire et cherche à savoir par quels moyens Dan aurait eu accès à ces informations critiques.
Selon les premières rumeurs, le jeune homme aurait infiltré un réseau de communication lui permettant de récupérer plus d'un millier de données sensibles dont seulement une centaine aurait été rendue publique. Ergstad aurait obtenu toutes ces informations sans en dévoiler les détails ni même être considéré comme hors la loi.
Quelques jours plus tard, le Sydney Morning Herald qualifie cet acte de "Hack of the year", récompense attribuée au pirate le plus ingénu de l'année .
Comment a-t'il fait ?
La méthode utilisée demeura quelques jours secrète.
Certains imaginaient alors que le pirate avait eu recours à des techniques de Man in the Middle évoluées (interception des données avant de les relayer vers la véritable destination) avec l'utilisation de certificats SSL...D'autres étaient certains que Egerstad avait piraté une agence secrète comme la NSA, ce qui justifierait l'accès à des données aussi confidentielles.
Grande déception pour les amateurs de hacking et d'intrusion dans les réseaux militaires américains, le pirate avait tout simplement positionné des noeuds Tor dans les 4 coins du monde et écouté leur trafic en sortie.
Le début de cette histoire remonte quelques mois en arrière. Le jeune homme travaillait pour une société de conseil en sécurité ce qui lui a permis de parcourir le monde afin de sécuriser des clients internationaux. L'idée de mettre en place plusieurs noeuds d'un réseau Tor lui vint alors à l'esprit. Quelques missions plus tard, 5 relais Tor étaient actifs sur Internet, prêt à espionner les utilisateurs du réseau Tor.
Après avoir fait la une des news sécurité sur Internet, Dan est arrêté par la police et est soupçonné d'avoir pénétré des serveurs étrangers. Il sera relâché après quelques heures d'interrogatoires.
Retour sur le fonctionnement de TOR
Le système est simple. Dan a mis en place beaucoup d'ORs dans le monde. Or nous avons vu que, si TOR implémente du chiffrement tout au long du circuit, il n'est pas possible pour ce dernier de chiffrer les données entre le dernier OR du circuit et le serveur destination :
Ayant mis en place beaucoup de serveurs dans le monde, il s'est assuré statistiquement qu'une partie d'entre eux seraient utilisés comme noeud de sortie, et n'a eu qu'à logger les données que ses noeuds relayaient !