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
Et d’ailleurs, les criminels discutent par mail. ‘Faudrait mettre tous les fournisseurs de mail en prison, notre sécurité à tous en dépend.
#97
#98
Oui, il y a effectivement I2P aussi, mais il n’est pas/peu utilisable dans ce cas, vu que comme tu le dis tu deviens serveur et client à la fois (plus galère à faire tourner sur une machine chopée in the wild).
#99
#100
Je peux me tromper, mais dans la trame TCP, il y a la MAC. A moins d’en changer continuellement, le modem est traçable, non ?
#101
La MAC change à chaque routeur. Tu ne peux pas utiliser la MAC pour tracer un équipement hors d’un réseau niveau 2 (switching)
#102
Non, il n’y a pas de MAC dans la trame TCP. MAC c’est au niveau de la couche de liaison (couche 2 OSI), ça ne passe pas le 1er routeur et ça se retrouve encore moins dans le gros ternet (couche 3&4).
#103
#104
#105
#106
j’espére ct de l’humour parce que ta remarque est complètement facho !
#107
Apparemment y’a un petit ver mineur de bitcoins qui a été découvert en même temps. Un peu plus discret lui par contre
" />
#108
après Wannacrypt il y a Adylkuzz qui s’introduit dans des PC vulnérables grâce à la même faille de Windows utilisée par WannaCry, un problème détecté par la NSA
#109
Adylkuzz bloque le port 445 et a limiter impact de wannacry . D’ailleurs adylkuzz ne mine plus de Monero la pool utiliser sans consentement a blacklisté les adresses utilisées
#110
Vous vous cassez le cul à débattre alors que les mecs qui ont fait ça ont peut être tout simplement acheter des smartphones + cartes sim prépayées jetables.
" />
Car oui un bon hackeur sait lancer une attaque de n’importe quel point d’entrée.
Donc à mon avis les équipements qu’ils cherchent à traquer sont déjà depuis longtemps recyclés ou entrain d’attendre leur tour en centre de tri pour déchets.
Vu l’ampleur de l’attaque, je doute que les mecs aient fait un One Shot après 2 jours de préparation seulement.
A mon avis, ca planait depuis des mois, ils attendaient juste une opportunité de passer à l’action.
Une opportunité où les différents services de sécurité et de protections soient occupés ailleurs et n’aient pas les yeux sur leur activité à ce moment là.
Et vu que les attaques semblent avoir massivement voyagé depuis la France, je dirais que cette occaz’ c’était Monsieur Macron en personne
Après ce n’est que mon avis mais le rapprochement des dates + les infos qu’on a pour le moment, ca me parait gros pour qu’il n’y ait pas de coïncidence.
#111
Je ne comprends pas pourquoi. Meme s’il y a 6 couches de chiffrement et N relays, il y a eu connexion avec les metadatas associés. Donc la possibilité statistique sur 10min si tu possèdes tous les logs de connexion de toutes les machines de calculer des proba des sources/targets reste possibles.
Peut etre que pour une target avec un nombre de connexion faible c’est peu probable d’avoir des chiffres probants. Je rejoints, NetworkSecExpert, une attaque de cette taille avec les logs associés doit necessairement augmenter la surface de detection pour trouver les cibles.
En passant, 1TB de metadata/semaine pour une machine, on ne parle meme pas encore de big data.
#112
> si tu possèdes tous les logs
de connexion de toutes les machines
Tu peux t’arrêter là. Comme signaler, il n’existe aucun log de cet ampleur. Même la NSA ne doit pas avoir un tel truc.
Même si de tels logs existaient, il faudrait la participation de l’ensemble des pays pour espérer pouvoir faire cette corrélation. Les nœuds en Afghanistan, en Suisse, aux Pays-Bas ou autres zones très protectrices (ou très j’en-foutisme, c’est selon), tu vas pouvoir te brosser pour les avoir.
Et même si tu les as, tu te retrouves avec des terrachiés de bouzillions d’information qui sont totalement inexploitables. Parce qu’on ne parle que de 1To de données au total pour mon nœud, mais il y en a un peu plus de 6000 nœuds en tout, dont des 3× plus rapides que moi. Et les informations nécessaires à la corrélation doivent être sur les paquets IP, qui transitent sur des dizaines de routeurs rien que pour faire client Tor → guard.
Et même si tu es arrivé ici, comme signalé plus haut, un nœud Tor établit des milliers de connexions avec ses petits voisins, donc pour un unique paquet qui arrive sur un nœud Tor, c’est un bon millier de connexions sortantes qu’il va te falloir analyser. ×3 couches (3 nœuds Tor par circuit Tor). Pour chaque paquet IP. Sur des liens à 100Mbps minimum voire 1Gbps pour les plus gros nodes.
Bref, à chaque seconde, ce sont des milliards de connexions possibles qu’il va falloir que tu parviennes à discriminer pour savoir laquelle correspond réellement au morceau que tu connais (client Tor→guard). Une fois passé le 1er nœud, tu ne peux que constater qu’il existe un bon milliard de circuits Tor établit à l’instant T de l’arrivée du paquet au cul du guard, sans avoir aucune possibilité de savoir quel circuit est réellement celui utilisé pour la communication de ton client Tor.
Et tous ces circuits sont en plus absolument indiscriminables les uns des autres en se basant uniquement sur des méta-données IP.
Tu es donc fucked. Point. Même avec l’historique complet mondial des méta-données TCP/IP.
Les 2 seules attaques théoriques sur le réseau Tor est l’attaque Sybil, puisque si quelqu’un contrôle plus de 66% des nœuds Tor, il a une chance non nulle d’avoir au moins 2 machines à lui sur les 3 d’un circuit Tor et donc de pouvoir désanonymiser tout le trafic qui passe par 2 de ses machines. C’est pour ça qu’on a fait blacklister immédiatement les machines saisies, pour qu’une telle attaque ne puisse pas être possible.
L’autre attaque est le flux shaping. Tu modules le trafic client→guard de manière à avoir un profil de trafic « reconnaissable », ce qui te permet de justement pouvoir discriminer les 1000 flux derrière puisque seuls ceux avec un profil compatible vont t’intéresser. C’est un problème difficile à résoudre pour les réseaux à faible latence comme Tor (I2P n’est pas à faible latence et fixe ce problème en lissant tout le trafic entre les nœuds).
#113
Il va surement le récupérer en même temps que sa fiche S, il pourra changer son pseudo en Saeris22.
#114
#115
Merci pour cette réponse.
Ce qu’il faut prendre en compte c’est l’ampleur de l’infection (+/- 200 000) qui pese statistiquement, le nombre de pays touché permettant une collaboration plus aisée, et la connaissance des IP et des timestamps sources.
Après pour être capable de répondre mathématiquement si oui ou non c’est possible il faudrait plus d’information sur notamment la fréquence d’utilisation de TOR par le malware, combien de noeuds ont pu avoir leurs logs de connexions saisies.
La question de la volumetrie de data n’est pour moins pas une problématique.
#116
> combien de noeuds ont pu avoir leurs logs de connexions saisies.
La réponse est simple 0. Il n’y a aucun log sur les nœuds Tor. Jamais.
Partant de là…
#117
Cette affaire a fournit une occasion en or pour accuser TOR, saisir des relais même si cela ne sert à rien pour l’enquête, et continuer à discréditer TOR dans l’opinion publique, ainsi que faire peur / dissuader les relais.
L’état n’en a rien à foutre de WannaCry qui infecte les entreprises et les administrations laxistes… mais fera tout pour lutter contre TOR, dissuader et menacer quiconque le facilite et l’utilise, puisqu’il s’agit du dernier espace de secret qu’il ne contrôle pas.
#118
Perso à minima je suis sur VPN + mac address spoofing. Sur mon tel, chiffrage + VPN et quelques softs sympas pour passer des appels sécurisé. Je vais mettre veracrypt sur mon prochain poste et un dual bool avec tails FFF.
#119
I2P est mature ?
#120
C’est complètement con.
A se demander si le but n’est pas juste d’essayer de porter atteinte au réseau en tapant sur les nœuds de confiance et en foutant la pression sur les hébergeurs.
#121
#122
@tout ceux qui - nous disent que Tor n’est pas vraiment anonyme et traçable, je voudrais qu’ils :
- nous expliquent pourquoi les organisations criminelles de toutes sortes iraient expressément sur TOR pour faire leur business malsain ?
C’est vrai, ces personnes pourraient tout autant le faire sur le web non-chiffré scanné par tous les moteurs de recherche après tout.
Soyons réaliste, Tor apporte bel et bien une anonymisation très difficile a tracer. Tout comme Bitcoin / la cryptomonnaie/blockchain rend très difficile le traçage des flux financiers illégaux.
Dire le contraire, c’est se soumettre a la crainte que veulent faire passer les autorités qui ont saisi ces serveurs TOR…
D’ailleurs, si des données permettant de retrouver les auteurs de la diffusions de ce ransomware sont retrouvés, alors certains chercheront a faire évoluer les nœuds TOR pour ne plus rien stocker du tout autrement qu’en RAM.
La course au chiffrement et a l’anonymisation est maintenant lancée a grande vitesse depuis l’affaire snowden et les révélations successives faites sur les techniques utilisée pr la NSA, la CIA et le GCHQ pour espionner le monde entier. Bien sur elle a tjrs existé, mais son accélération est tout de même flagrante. Il suffit de regarder l’intégration de puces de chiffrement dans les appareils grand publics.
#123
#124
#125
Il fut un temps où la CNIL recommandait TOR pour surfer et préserver la confidentialité.
#126
Voila! La prochaine fois que vous crevez, vous pourrez signifier que c’est l’asphalte de l’autoroute empruntée qui a usé votre pneu et porter plainte contre celle-ci. Peu importe la raison de la crevaison.
#127
J’ai mieux. Si vous vous faite cambrioler, allez demander a la mairie que la rue devant chez vous soit interdite d’accès car c’est celle-ci que le cambrioleur a emprunté.
#128
#129
#130
Non, par défaut les nœuds ne loggent rien. Je pense même que techniquement, rien n’est codé pour permettre un tel journal. La proba de tomber sur un nœud qui log quelque chose est donc vraiment très très très très faible. Je dirais même qu’elle est de 0 sans prendre beaucoup de risque (sinon un nœud malveillant).
#131
Je connais mal tor, mais c’est juste un service qui tourne le plus souvent sur un linux ou bsd, non ? Donc t’as une debian (par exemple) standard, et dessus un service tor. Ou alors, tu as une vraie distribution « tor-box » clé en main qui garantit que tout est bien configuré ?
Je crois volontiers que le service en lui-même ne logge rien, en revanche, on peut peut-être trouver des traces à d’autres endroits (logs kernel / iptables, par exemple).
#132
J’ai un beau frère qui est persuadé que la NSA est capable de décrypter (j’utilise le bon terme) les messages qu’on envoie depuis un ProtonMail ou un Silence.
Même après que je lui ai dit que la NSA n’avait pas pu repérer les messages de Snowden.
#133
C’est généralement un OS standard sur lequel on vient installer Tor.
Les opérateurs de nœuds sont plutôt bien conscient des problèmes et installent correctement les choses.
Au niveau du kernel ou du firewall, personne n’est assez con pour activer un niveau de log aussi détaillé (IP source/destination pour CHAQUE paquet TCP entrant et sortant). Tu fusilles ta machine en 10min si tu actives un tel log de toute façon (300Mbps de trafic symmétrique dans mon cas = bobo les disques et la latence réseau…).
Et comme déjà précisé, même si un tel log existe, il est inexploitable : tout le trafic sortant de ma machine n’était que de la communication avec d’autres nœuds Tor (donc ni un client final ni un service caché ni quoi que ce soit d’autre qu’un des 6000 autres nœuds Tor du réseau). Donc tu n’en apprendras strictement pas plus que si tu n’avais pas eu ce log.
La collecte des logs sur des nœuds Tor n’est pas décemment pas envisageable si tu veux remonter à une source ou à une destination. Va te falloir trouver autre chose. Et donc arrêter de saisir les nœuds.
#134
#135
#136
Change de beau-frère.
Même si la NSA avait cette puissance de frappe (elle l’a effectivement sûrement sur le papier), elle réservera son usage à des cas extrêmements spécifiques vu le coût astronomique pour péter ce genre de choses.
C’est exactement pareil pour la France hein, ils ont des moyens « secret défense » utilisables si besoin pour péter de la crypto même très robuste. Juste ils ne s’en serviront jamais pour un pékin moyen.
#137
#138
Et quelle est la proba que le fournisseur du serveur logs les connexions?
#139
0 aussi. Trop consommateur en temps et en ressources, trop intrusif sur le réseau, trop de données à collecter et à stocker. Pour une utilité proche du 0.
#140
Le seul trafic intéressant à logger sur TOR, c’est celui d’un nœud de sortie, en tablant sur le fait qu’il y ait des infos intéressantes à chopper, et il faut réussir à ne pas se faire chopper sinon c’est le ban du réseau.
#141
Il n’y a aucun nœud de sortie dans le cas de wanacry. Ça utilise des .onion, donc ça reste 100% en interne du réseau Tor. Le C&C n’est qu’un client Tor comme les autres, au même titre que toutes les machines infectées.
#142
#143
Du coup, comment ça se passe ? À un moment, l’un des nœuds doit bien « savoir » que le prochain nœud est le service .onion, histoire de router vers le bon.
Je suppose donc qu’il y a une table de routage quelque part, qui dit « pour tel service .onion, utilise tel nœud ». Et cette table, elle est stockée en RAM, non ? (c’est peut-être ça dont tu parles qui est remis à jour toutes les 10 minutes).
En supposant la saisie bien faite, n’y a-t-il pas moyen de dumper (depuis la ram, donc) ces tables de routage sur tous les serveurs, et ensuite, par une approche statistique, déterminer l’ip du .onion que tu cherches ?
#144
Merci pour ces précisions :)
#145
Je ne sais pourquoi une petite voix me dit que l’objectif de cette descente c’est de figer une capture. Vu l’ampleur de l’attaque le bruit a certainement été mesuré et doit très probablement être stocké quelque part dans l’une des fermes continentales, ici on doit être sur la partie analytique du trafic et un élément utile doit certainement se trouver dans ces saisies… ^¿^
#146
Ça ne fonctionne pas vraiment comme ça avec les services cachés.
Le C&C va se connecter au réseau Tor, avec un simple client Tor indistinguable des autres clients.
Choisir quelques relais au pif (les introductions points), les contacter en établissant un circuit Tor (3 relais) et leur dire « si quelqu’un demande xxxx.onion, merci d’utiliser ce circuit ». Les introductions points publient dans une DHT gérée par l’ensemble des nœuds dit « HSDir » en disant « si vous voulez contacter xxxx.onion, vous pouvez joindre les introductions points suivants »
Quand un client Tor standard veut accéder à xxx.onion, il demande aux HSDir quels sont les introductions points (toujours via un circuit Tor hein !), se connecte à l’un d’entre eux, et est mis en relation avec le service caché (derrière un circuit Tor lui-aussi donc).
Ni le HSDir ni l’introduction point ne connaissent l’adresse IP réelle de quelqu’un, ni du service caché ni du visiteur du service caché.
Saisir les nœuds Tor n’apprendra rien de plus :
Bref, laissez les nœuds Tor tranquille SVP, ça ne sert à rien de les saisir…
#147
Merci pour les explications
" />
#148
Ca faisait longtemps que les commentaires d’une news n’avait apporté autant d’informations techniques 
" />
#149
C’est parce que c’est un article gratuit, sur les articles payants les commentaires sont nazes ! 😁
#150
#151
et pour tout ceux qui rêve de “ahaha j’ai chiffré mon ordinateur avec rsa 4096 personne ne pourra savoir ce que j’ai”, je rappellerais:
 https://www.xkcd.com/538/
Il y a plein de façon différente de prendre la main sur un terminal, et croire que les services de renseignements , qui sont des professionnels du renseignement, n’ont que le brute force d’un message envoyé sur un réseau risque d’avoir quelques déconvennues si ils intéressent vraiment les services.
Ensuite c’est un rapport “cout/bénéfice”. Par exemple si ils peuvent rooter tous les téléphones en un clic , ils l’utiliseront massivement. Si il faut avoir une compromission physique, il faut avoir fait plus que juste envoyer un sms chiffré à ta mère/femme/… pour qu’ils prennent la peine de savoir ce qu’il y a dans le message.
Sachant que le plus intéressant est rarement le message, mais les métadata.
#152
C’est pour éviter le syndrôme « clef à molette » que je fais aussi très gaffe avec des systèmes 2FA ou autres.
Même en me cassant les genoux, si je n’ai pas accès à ce dont j’ai besoin, je ne suis pas en mesure de donner les infos nécessaires au déchiffrement :)
#153
#154
La méthode de la clé à molette a aussi le bon gout (ou mauvais, selon comment on regarde), de garantir qu’on soit au courant de s’être fait piraté.
Aussi, l’aspect peu automatisable et particulièrement intrusif de la chose en limite l’applicabilité à quelques cas particuliers (un peu comme la possibilité potentielle pour la NSA de casser du protonmail : peut-être, mais pas à grande échelle).
#155
Quid du fait que les terminaux peuvent avoir été vérolés avant, par exemple dès leur conception, ou lors de leur expédition dans le pays où ils vont être commercialisés, ou par une application pré-installée, etc. (la liste des scénarios pourrait être longue).
A ce moment là, peu importe la cryptographie qui est utilisée, nul besoin de la casser, les secrets sont connus.
Plus d’infos :https://www.youtube.com/watch?v=cyOJiJYUnGA
#156
Si ton VPN est sur le territoire français, ce n’est pas très malin.
#157
c’est exactement mon impression.
diminuer le nombre de serveurs guard, et qui sait, ils vont surement monter leurs propres serveurs TOR discrètement, histoire de posséder par exemple plus de 66% des serveurs TOR dans le pays.
En saisissant les serveurs guard existants, ils mettent le bordel dans le réseau TOR, et font monter leur ratio.
En plus, les propriétaires se font surement ficher S
#158
#159
Et j’ajouterais : Avez-vous l’intention de remonter un noeud équivalent ?