Entre vendredi et lundi, plusieurs relais français du réseau d'anonymisation Tor ont disparu des écrans radar. Selon nos informations, ils ont été réquisitionnés par la justice, dans le cadre de l'enquête sur le ransomware WannaCrypt, qui s'appuie sur Tor pour communiquer avec son serveur de contrôle.
Il y a du trafic qu'il ne vaut mieux pas relayer. Celui du ransomware WannaCrypt, qui a infecté plus de 200 000 appareils dans le monde en quelques jours, mettant à mal certains systèmes industriels, en fait partie. Rapidement ciblé par plusieurs enquêtes, notamment d'Europol, il est à l'origine de la réquisition de plusieurs nœuds du réseau Tor chez des hébergeurs français.
Pour mémoire, WannaCrypt s'appuie sur une faille conservée par les services de renseignement américains, pour infecter des systèmes Windows obsolètes via le protocole réseau SMBv1. Pour communiquer avec le serveur de commande et contrôle (C&C), c'est Tor qui est utilisé. Du point de vue de la victime, c'est donc le nœud d'entrée du réseau « anonyme » qui est visible.
L'OCLCTIC de bon matin
Au moins trois serveurs ont ainsi baissé le rideau ce week-end, suite à la visite de l'Office Central de Lutte contre la Criminalité liée aux Technologies de l'Information et de la Communication (OCLCTIC) chez ces acteurs, saisissant le contenu de ces relais. Il s'agirait de « guard nodes », c'est-à-dire de points d'entrée de confiance pour le réseau Tor, à la fois par leur disponibilité et leur bande passante.
Selon nos informations encore, ces disparitions sont dues à « une très grande vague » de perquisitions et saisies, concernant au moins plusieurs dizaines de disques durs. « Tous les relais Tor qui ont participé à cette attaque ont été saisis » nous affirme-t-on. Les principaux hébergeurs français seraient concernés par cette salve.
Des disparitions inexpliquées
L'intervention de l'OCLCTIC pourrait suivre une demande de l'Agence nationale de la sécurité des systèmes d'information (ANSSI). Contactée, cette dernière n'a pas encore répondu à nos sollicitations.
« On a épluché les journaux du consensus des nœuds Tor. Entre vendredi et lundi, des dizaines de gros nœuds ont disparu du réseau. Il n’y a pas de raison que de tels nœuds disparaissent comme ça » affirme par ailleurs un spécialiste de Tor, contacté par nos soins. Au moins une partie des relais ont été coupés volontairement, sans intervention des autorités.
Interrogé, OVH n'a pas répondu à nos demandes. Pour leur part, Gandi et Online se sont refusés à tout commentaire. Enfin, le ministère de l'Intérieur refuse de s'exprimer sur une enquête en cours. Il renvoie vers le parquet de Paris, injoignable pour le moment.
Commentaires (159)
#1
Enfin, le ministère de l’Intérieur refuse de s’exprimer sur une enquête en cours. Il renvoie vers le parquet de Paris, injoignable pour le moment.
En même temps normal, ils sont tous à attendre la nomination du nouveau gouvernement " />
#2
Mozilla va en remettre en service rapidement?
#3
Quand on vous sit que ce sont des criminels chez TOR… A la fois les concepteurs, les utilisateurs et ceux qui hébergent les noeuds….
Je te mettrais tout ca en prison, notre sécurité a tous en dépend.
#4
Ah bah tiens. Et ils esperent trouver quoi sur ces relais exactement ? Les logs etant probablement en RAM comme a l’epoque de razorback, je ne vois franchement pas l’utilite.
#5
#6
Les logs ? Quels logs ? Il n’y en a juste pas sur les relais Tor.
#7
c’est ce que tous le monde pense , il y toujours des logs quelque par ,
les fai et hébergeur sont obligé de loggé les activités entré sorti , aussi sous certaine loi les logs sont obligatoire et les Os garde souvent des trace de connexion, en plus si ils font tombé les noeuds les arnaquer de wanna crypt vont se faire plus facilement repéré
même si tor ne log rien qui dit que le host lui n’a pas un syslog de configuré pour enregistré les va et vient de la machine
#8
Enfin, le ministère de l’Intérieur refuse de s’exprimer sur une enquête
en cours. Il renvoie vers le parquet de Paris, injoignable pour le
moment.
Lequel ? Le nouveau ou l’ancien ?" />
#9
#10
Je suis un des nœuds saisis. Je te garanti qu’il y a 0 log. Rien n’est tracé, rien n’est stocké. Aucune information utile, aucune IP, aucun journal.
Et même si log il y avait, je n’étais de toute façon que le 1er maillon de la chaîne Tor qui en comporte 3, donc sans aucune information sur la vraie machine liée à l’infection Wannacry. La seule machine que je voyais était la machine infectée en entrée, et un autre nœud Tor (le middle cette fois) en sortie. Rien d’autre.
#11
#12
Faut-il encore rappeler de nos jours que Tor a été inventé par le laboratoire de recherche de la marine américaine…?
#13
#14
#15
#16
#17
#18
#19
Ils n’ont pas ce genre de log. Et même s’ils l’avaient, ça ne servirait strictement à rien dans le cadre de l’enquête. Aucune des IP dedans n’est responsable dans l’infection Wanacry (une des machines est la machine infectée, l’autre est juste l’équivalent d’une porte d’entrée publique permettant de communiquer avec le réseau Tor).
#20
#21
Non. Online n’a aucune obligation de stocker ce genre d’information. Ce niveau de détail serait de toute façon instockable tellement les informations seraient collosales (mon nœud Tor générait 300Mbps de trafic en continu, soit 1To de données par semaine).
#22
Perso je fais VPN + TOR, sur mon pc, sur mon téléphone Tor + Tor bridge + VPN
#23
exacte
moi-même je log les in et out de mon réseau via le routeur avec syslog et un dossier séparé pour le serveur mincraft/l4d/tf2
#24
#25
#26
Ca permettra de tracer l’ordre des machines infectées
#27
#28
#29
#30
#31
loi no 2006-64 du 23 janvier 2006 relative à la lutte contre le terrorisme -> l’article 6, qui impose aux opérateurs télécoms, aux fournisseurs d’accès (FAI), mais aussi à tout établissement public proposant un accès internet, comme les cybercafés, de conserver les données de connexion (logs) pendant un an
#32
#33
#34
Ha, j’ai sorti l’article 6 de la loi contre le terrorisme, que dit cet Article 1 de la LCEN ?
#35
#36
Oui mais tu peux logger uniquement le fait de s’être connecté à un service VPN ou bien à Tor, c’est pas un crime en soit.
#37
#38
#39
#40
Vu que la LCEN date de 2004, et que l’article 1 de la LCEN est la définition de ce qu’est un réseau, je vois mal en quoi un hypothétique article 1 de 2001 imposerait quoi que ce soit à une entité comme Online (qui n’est pas hébergeur de contenu, mais opérateur de réseau).
#41
#42
Haha, non non c’est pas une crime :)
Je veux juste dire que le log est inutile. Tu peux rien en faire.
#43
#44
Oula… Jamais, au grand jamais, de Tor over Tor. cf le risque de passer par le même nœud.
Et VPN over Tor est inutile aussi, ça ne fait que faire passer en VPN via Tor, donc aucune anonymisation supplémentaire. De plus, en France, les VPN sont légalement obligatoirements loggés.
#45
#46
L’anonymité au sein même du réseau Tor, donc quand tu accèdes à des domaines .onion est quasi parfaite. Mais une fois que tu sors du réseau elle n’est plus 100% garantie. Des chercheurs ont réussit à lever l’anonymat de certaines personnes en analysant les patterns de connexion. Quand tu te connectes toujours du même pc à Tor, en analysant les noeuds de sortie tu peux faire des déductions.
#47
#48
Si je monte un VPN pour mon usage exclusif je suis sensé le logguer ?
Certain qu’il y a quelque chose comme “un accusé n’est pas obligé de se charger lui-même” en Droit qui fait qu’on peut bien s’assoir là-dessus pour ce cas-ci
#49
C’est Tails la distribution, Kali est aussi utilisable.
La disparition de ces noeuds expliquent pourquoi c’était lent ces derniers jours par moment (bon tout dépend d’où tu sors)., moi qui avait besoin de ma dose de vidéo pedonazi-terroiste lunaire*
* matez IronSky, c’est complètement décalé comme film.
#50
#51
Si il est autohébergé, pas de problème là " />.
Mais inutile de mettre un VPN si c’est pour passer via Tor.
#52
#53
Ha mais tu as tout à fait raison, VPN dans un pays sans contrôle + Freenet/Tor/I2P c’est robuste, mais c’est pas 100% infaillible, y’a toujours des traces. Aucun système n’est parfaitement sécurisé, aucun système n’est parfaitement anonyme, y’a toujours un point faible.
Le mec de SilkRoad c’est fait choper car il a utilisé le même pseudo sur stackoverflow et ils ont ensuite vu qu’il se connectait souvent à Tor, alors c’est pas une faiblaisse du réseau Tor, mais ça monte que t’es jamais 100% couvert.
Je parlais de ce payer dans mon post (il me semble que c’est lui)->http://sec.cs.ucl.ac.uk/users/smurdoch/papers/oakland05torta.pdf
#54
#55
#56
#57
#58
#59
Pardon monsieur, je ne referais pas cette erreur " />
#60
#61
#62
il vont pas y trouver grand chose… ca garde pas de logs ces bidules la…
#63
Je ne suis pas hébergeur de contenu. Je n’ai même aucun contenu.
Je suis équivalent ou en tout cas plus proche d’Online (je fournis un réseau dans le réseau, je ne fais que véhiculer des petits paquets dont je n’ai même aucune sorte d’idée de ce que ça peut bien être) que d’un hébergeur (hébergement du contenu). Et aucune loi n’impose de loger quoi que ce soit dans ce cas.
Les seules obligations actuelles que je connaisse sont
1- obligation de log des IP distribuées à leurs clients par les FAI (date, IP et identité du client)
2- obligation de log côté serveur web d’un hébergeur (date, IP du visiteur, contenu visité)
#64
Office Central de Lutte contre la Criminalité liée aux Technologies de l’Information et de la Communication
Sacré nom " />
#65
Du coup, sais-tu si tu as une chance de revoir ton serveur un jour ?
#66
#67
Je préfère ne pas compter dessus :P
Il y a certainement une chance non nulle, mais dans trop longtemps et sans garantie. Donc autant considérer les données perdues (et ça sert à ça les backups, se protéger de Wannacry et se protéger de ceux qui ne se sont pas protégés de Wannacry :P)
#68
#69
La saisie va permettre se remonter les commanditaires assez simplement… car le virus Wannacrypt téléchargeait le client tor pour pouvoir communiquer avec le serveur de contrôle hébergé en “hidden service”.
Pour remonter la source du serveur de commande, au vu du nombre d’infection, les choses vont aller très vite.
Le principe est le suivant, admettons que certains hébergeurs conservent les métadonnées de connexions ou que ces métadonnées soit obtenues d’une façon ou d’une autre (via par exemple les systèmes de surveillances des télécommunications nationaux) alors ils vont procéder de la sorte par recoupement :
L’utilisation du réseau tor dans ce cas là permet de se cacher un temps mais pas rétroactivement après analyse et donc j’espère pour les commanditaires qu’ils ont pris leurs dispositions au niveau des traces qu’ils auraient pu laisser sur les serveurs de commande. L’histoire nous le dira, mais pensant ne pas être retracé par l’utilisation de tor de leur virus alors ont-ils surement été imprudent dans l’achat/utilisation/configuration de leurs serveurs de commandes.
Wait And See.
#70
#71
#72
Je ne suis pas un expert, mais tu pars du principe que le serveur C&C n’est constitué que d’un seule entité.
Si il y en a plusieurs, toute la démarche tombe à l’eau.
#73
Vu le nombre d’infections et donc de connexions a établir, il faudrait un nombre assez important de serveurs pour qu’ils soient difficiles de les remonter par recoupement.
Si on part sur 200 000 infections avec chacune au minimum 20 connexions au(x) serveur(s) de commande alors ça fait plus de 4 000 000 de requêtes de connexions en l’espace de 3 jours… un trafic inhabituel qui se retrace facilement par recoupement des métadonnées.
#74
Mais dans ton explication ne faut-il pas avoir accès à la fois aux serveurs d’entrée de sortie et aux middle ? Ca ne fait pas beaucoup ?
#75
Laxiste. C’est à cause de gens comme toi que tout part en couilles.
JE RECLAME LA PEINE DE MORT!!!
#76
@soupêtte :
#77
Sauf que:
Concretement avec tous ces beaux chiffres, tu vas te rendre que des connexions vont en masse vers certains noeuds TOR dans divers pays et fin de l’histoire. D’autant que, comme souvent, les C&C sont variables et places sur des machines deja infectees. Il est extremement rare de remonter au C&C root donc pas trop d’espoir a ce niveau la.
#78
Sauf que les nœuds Tor sont conçus pour que même une correllation de traffic soit assez difficile à réaliser, sauf à avoir VRAIMENT de très gros moyens à disposition.
Mon nœud générait 1To de données par semaine, et avaient des milliers de connexion Tor ouvertes en permanance. Bon courage pour la corrélation.
Bon courage aussi pour la coordination internationale, la sélection des nœuds utilisés pour un circuit Tor impose le passage par 3 pays différents !
Et sachant qu’il n’y a aucun log sur ces machines, leur saisie était de toute façon totalement inutile !
#79
OK mais tu sous-entends donc qu’ils auront accès à des serveurs à
#80
Nul ne sait vraiment ce qui est écrit dans une machine tant qu’il n’a pas lui-même conçu le programme. C’est un principe de base en sécurité; Rien n’est fiable et sûre.
Après peut-être que je me trompe mais vu l’ampleur, je doute qu’ils saisissent des serveurs sans raisons.
Et je ne parle même pas du fait que les gouvernements peuvent être eux-même propriétaires d’une multitude de serveurs de sortie avec lesquels ils vont pouvoir faire des recoupements encore plus facilement juste en procédent à l’analyse des ip’s de sorties.
#81
#82
Ou pas justement. Ça va être du trafic qui va être reporté aléatoirement dans le réseau Tor. Ça va foutre un bordel pas possible pour recouper tout ça. Et en prime ça suppose que tu aies accès aux méta-données (dont je doute déjà de l’existence…) de l’ensemble des nœuds utilisés (donc de 3 pays différents, obligatoirement), pour chaque connexion. Sur 2 millions de connexion (soit 6 millions de sauts Tor, sans parler qu’ils sont renouvelé toutes les 10min…), c’est l’intégralité des logs du trafic planétaire qu’il te faut…
Et si tu as accès à ces méta-données, tu n’as certainement pas besoin de saisir les machines. Qui ne contiennent aucune info de toute façon.
#83
Peut-être que tu as raison mais en tous cas, sur une attaque de cette envergure je ne me baserai sûrement pas sur TOR pour assurer mon anonymat et celui des serveurs de commandes.
Dommage que je n’ai pas le courage de mettre en place un serveur de sortie (Je ne veux pas être ennuyé par les problèmes potentiels que ça pourrait générer) avec conservation des métadonnées pour les passer à la moulinette sur le weekend de terreur afin par exemple, d’éliminer les ip connues du 01/2016 au 12⁄2016 pour ensuite avoir un échantillon d’ip nouvelles et donc possiblement dans ces ips les ips des serveurs de contrôle.
Les méthodes pour remonter à la source sont assez nombreuses pour des attaques de cette taille.
#84
Les circuits Tor changent toutes les 10min. Et j’ai bien indiqué aussi derrière que j’avais des milliers de connexion ouvertes en permanence sur ma machine.
Donc même en saisissant ma machine, même si j’avais des logs (ce qui n’est pas le cas), tu aurais 1000 machines à aller saisir pour aussi espérer des logs, dans a minima une 10aine de pays, te menant à 1000 machines pour chaque machine saisie. Et donc un bon petit million de machines (soit tout le parc des nœuds Tor en fait) si tu veux espérer remonter à la source des données (3 nœuds par circuit).
Bref, c’est juste peine perdue.
#85
Le C&C est dans un .onion. Il n’y a pas de guard ni d’exit node dans ce cas. Le trafic reste 100% à l’intérieur de Tor, tu n’auras donc strictement rien à comparer entre avant et après.
#86
#87
Si tu n’es pas trop bête (les erreurs de SilkRoad & autres étaient humaines, pas techniques), Tor est un excellent moyen de te mettre à l’abri. Certainement le meilleur (sinon le seul d’ailleurs) qui existe aujourd’hui.
#88
J’ai réinstallé mon serveur y a environ 1 mois chez OVH et par manque de temps j’ai pas remis le bridge tor en place. Ouf :) ça m’aurait fait chier de perdre les autres trucs qui tourne dessus!
#89
Le trafic reste dans tor mais il n’empêche que le nœud de sortie lui se connecte bien à l’hidden service et donc à la machine qui héberge les serveurs de commande.
Simplement le trafic entre le nœud de sortie et le hidden est chiffré via tor, ni plus ni moins.
#90
Il n’y a pas de nœuds de sortie sur les services cachés.
Le service caché et le client se rencontrent sur un nœud pris au pif (l’introduction point), il y a donc 6 couches de chiffrement, et l’introduction point ne connaît ni l’identité du client (1 circuit de 3 nœuds entre lui et le client) ni le service caché (pareil).
Tu n’as donc aucun moyen de remonter à la source. Même en saisissant toutes les machines.
#91
On va gratter l’oignon de bon matin " /> " />
Je ne suis déjà plus là …
#92
Le principe reste le même:
une ou plusieurs IP’s qui avant n’existaient pas sur le réseau se mettent à se connecter à des nœuds et elles le font en quantité importante vu le nombre de machines infectés.
Pour reprendre ce que je disais:
Une machine tor fonctionnant depuis 2 ans et qui log les métadonnées, pour détecter les “nouvelles” ip, je décide de supprimer de mes métadonnées toutes les ips connues depuis la possible mise en test du virus, soit disons la date de sortie publique de la faille trouvé par la nsa.
Il me reste donc toutes les ips nouvelles entre la période de publication de la faille et aujourd’hui, il reste ensuite à faire une statistique des ips les plus vu en connexion le semaine d’avant la diffusion du virus, puis de refaire la même chose après la diffusion du virus.
De cette liste va forcément apparaître les ips des serveurs de commandes, et à plus forte raison si les gouvernements ont des dizaines de serveurs tor.
#93
ça semblait marcher vachement bien chez numéricable , qui avait déjà du mal à fournir les adresses pour une ip leur appartenant
https://www.nextinpact.com/news/98964-hadopi-et-identification-ip-cnil-adresse-a…
#94
Non, il n’y aura pas « d’IP à apparaître ». Tu ne verras que X CLIENTS Tor supplémentaires, et encore en espérant que tu sois Guard (ce qui ne sera pas le cas si tu as un comportement mauvais pour le réseau d’ailleurs). Sinon tu ne verras juste rien du tout puisque tu ne fais que discuter avec des nœuds Tor (middle ou exit, puisqu’ici tu n’as pas de vrais exit vers le dehors du réseau).
Donc tout ce que tu peux lister, c’est l’arrivée massive de toutes les machines infectés.
Le HS lui, il sera apparu X mois avant bien tranquillement quand il n’y avait encore personne à s’intéresser à Wannacry, ou bien noyé dans le gros bordel de machines compromises.
#95
Vu que la connexion passe par plusieurs nœuds tor, tous les nœuds intermédiaires ont leur connexions qui augmentent d’autant. Donc tu ne peux pas savoir quel nœud demande plus qu’avant (puisque tu ne sais pas quel est le nœud d’origine). Donc tous les nœuds sont autant suspects les uns que les autres et t’es pas plus avancé…
Edit : zut, grillé par aeris22 de quelques minutes " />
#96