Ç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 :
Les HSDir se répartissent la DHT (d’où le D de DHT), donc vous ne pouvez pas lister facilement tous les introductions points d’un service caché
Si tu as du bol de saisir un introduction point, déjà dès que tu le fous offline, tu perds de toute façon le circuit Tor du service caché (qui changera de toute façon régulièrement) et même en le gardant online, ben tu ne fais que voir un autre nœud Tor (vu qu’il y a un circuit Tor entre l’introduction point et le service caché)
Si tu saisis une autre machine, pareil, tu n’as aucune info supplémentaire, tu vois juste au mieux le client du service caché si tu tombes sur un guard, mais tu n’as aucun moyen de savoir que c’est bien lui (vu que le circuit ira vers un middle derrière, qui n’est ni l’introduction point ni le hsdir ni le service caché), et dans tous les autres cas tu ne verras que des tas de circuit Tor non identifiable…
Bref, laissez les nœuds Tor tranquille SVP, ça ne sert à rien de les saisir…
Le
18/05/2017 à
15h
18
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.
Le
18/05/2017 à
15h
11
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.
Le
18/05/2017 à
14h
31
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.
Le
18/05/2017 à
14h
28
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.
Le
18/05/2017 à
14h
08
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).
Le
18/05/2017 à
09h
54
> 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à…
Le
18/05/2017 à
08h
47
> 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).
Le
17/05/2017 à
19h
19
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).
Le
17/05/2017 à
18h
19
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).
Le
17/05/2017 à
17h
58
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.
Le
17/05/2017 à
17h
05
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.
Le
17/05/2017 à
16h
27
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.
Le
17/05/2017 à
16h
19
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.
Le
17/05/2017 à
16h
18
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.
Le
17/05/2017 à
16h
07
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.
Le
17/05/2017 à
15h
50
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 !
Le
17/05/2017 à
15h
15
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)
Le
17/05/2017 à
15h
01
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é)
Le
17/05/2017 à
14h
15
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).
Le
17/05/2017 à
14h
00
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).
Le
17/05/2017 à
13h
58
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).
Le
17/05/2017 à
13h
42
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.
Le
17/05/2017 à
13h
31
Les logs ? Quels logs ? Il n’y en a juste pas sur les relais Tor.
mais, j’insiste, ce n’est pas que pour cette raison que c’est non inversible
En fait si, la condition de collision est suffisante pour garantir la non réversibilité d’une fonction.
Tout algo connaissant des collisions est non réversible puisqu’au moins 2 valeurs de départ pointant sur la même valeur d’arrivée, il est impossible de décider quelle est la “bonne” valeur de départ à partir d’une de ces valeurs.
Par contre c’est effectivement une mauvaise idée de se servir de cette propriété en cryptologie et surtout en hashage, puisqu’une bonne fonction de hashage doit justement minimiser les collisions.
Dans le cas de SHA2, on sait qu’il existe forcément des collisions puisque l’ensemble de départ (tout :P) est infiniment plus grand que l’ensemble d’arrivée ([0-2^256]) et donc qu’il existe même une infinité de valeurs possédant le même hash. Et donc que la fonction est mathématiquement non inversible.
Cryptographiquement, on va plutôt raisonner en restreignant l’ensemble de départ à aussi [0-2^256]. Comme SHA2 est une bonne fonction de hash cryptographique, il se trouve qu’elle va être très proche d’une bijection de [0-2^256] sur [0-2^256], donc n’avoir que peu de points en doublon, et donc être théoriquement inversible (« presque partout » comme diraient les mathématiciens).
La vraie définition de l’inversibilité en crypto est surtout qu’il n’existe pas de manière plus efficace de calculer cette pseudo-bijection inverse que celle consistant à fabriquer la table inverse par force brute en calculant chaque image pour chaque valeur de [0-2^256]. Et aujourd’hui, en l’état des connaissances, c’est juste physiquement impossible de travailler sur des données aussi collosales qu’un espace de 256 bits (espace de stockage supérieur aux nombres d’atomes constituant l’Univers), temps de calcul dépassant l’âge actuel de l’Univers, …).
Le
10/02/2017 à
17h
23
OlivierJ a écrit :
Je n’avais pas vu ça, car je pensais qu’un sel commun à tout le monde revenait à modifier la fonction de hashage. Tu es sûr que ça revient tout à fait au même ? Qu’on peut obtenir le même hash recherché sans le sel ?
Si le sel est commun, disont SSSS, ça revient à transformer un bruteforce de tous les XXXX vers HHHH en tous les SSSSXXXX vers HHHH. Donc plutôt que de générer des données au pif, de calculer le hash et de vérifier s’il est dans la table, tu vas générer une donnée au pif, lui foutre SSSS devant, hashé et vérifier la base.
Autant dire qu’en terme de complexité pour l’attaquant, tu n’as strictement rien changé, il pourra toujours comparé chacun de ses hashs calculés avec l’ensemble de la base.
Avec un sel par utilisateur, il devra faire la même procédure pour chaque utilisateur, ralentissant son attaque d’un facteur égal au nombre d’utilisateur.
Le problème est bien visible avec un exemple.
Pas de sel ou un sel partagé
Utilisateur 1 : HHHH
Utilisateur 2 : IIIIII
Utilisateur 3 : JJJJ
Utilisateur 4 : HHHH
Déjà je vois immédiatement que 1 et 4 ont le même pass.
Je génère des tonnes de pass aléatoires, l’un d’eux (pppp) me donne HHHH. J’ai donc le pass de 1 ET de 4.
Si j’ai un sel partagé SSSS, je calcule juste hash(SSSSpppp) au lieu de hash(pppp), si ça me donne HHHH, j’ai aussi le pass de 1 ET de 4. Durant mon parcours des nombres aléatoires, j’ai aussi très bien pu trouver IIII et JJJJ, et donc avoir casser 2 et 3 au passage.
Sel unique
Utilisateur 1 : SSSS|HHHH
Utilisateur 2 : TTTT|IIIIII
Utilisateur 3 : UUUU|JJJJ
Utilisateur 4 : VVVV|KKKK
Bien que 1 et 4 utilisent le même mot de passe, je n’ai déjà plus la possibilité de le deviner a priori.
Je génère des tonnes de pass aléatoires, l’un d’eux (pppp) concaténé avec SSSS me donne HHHH. J’ai donc le pass de 1. Je ne peux pas deviner que j’ai aussi le pass de 4, puisqu’il aurait fallu que je calcule aussi VVVVpppp ce que je n’ai pas fait… Même si au court de mon parcours je tombe sur IIII à partir de iiii, j’ai en fait calculer hash(SSSSiiii) = IIII, et donc ça ne veut absolument pas dire que j’ai trouvé le passe de 2, puisqu’il aurait fallu en fait que je calcule hash(TTTTiiii)…
Bilan : avec un sel unique pour chaque utilisateur, un attaquant est incapable de casser plus de 1 utilisateur à la fois, alors qu’avec un sel partagé ou pas de sel du tout, il va casser tous les utilisateurs d’un coup. Ou encore dit autrement, en ayant parcouru l’ensemble des valeurs des 2^256 possibilités de SHA2, il n’aura trouvé qu’un seul utilisateur avec un sel unique alors qu’il aura trouvé TOUS les utilisateurs sans sel ou avec un sel partagé.
Le
10/02/2017 à
16h
21
OlivierJ a écrit :
C’est moche non ? En tous cas je ne ferais pas ça vu l’importance du sel.
Le sel n’est pas critique et n’a aucun intérêt à être caché. Sa publication ne change rien à la sécurité, son objectif est uniquement d’empécher un bruteforce massif de la table et d’obliger un attaquant à travailler par utilisateur.
Dans tous les cas, comme il doit être unique par utilisateur, ça sera difficile de le garder planquer.
Certains le code en dur, mais il est du coup commun à tous les utilisateurs et ne sert alors à rien (on bruteforcera toute la base comme s’il n’y avait pas de sel).
OlivierJ a écrit :
Histoire d’être certain :
si la base de hash est salée et que le sel n’est pas en possession de l’attaquant, c’est mort non ?
si on dispose du sel, avec une bonne fonction de hash, j’imagine que trouver un mot de passe qui génère le hash recherché, ça peut prendre un temps dingue, non (vu que c’est le but du hash d’empêcher la chose) ?
Si le sel n’est pas en possession de l’attaquant, c’est mort, mais pas pour l’attaquant, pour toi. Ça veut dire que tu as raté quelque chose sur le principe du sel :P Cf juste au-dessus.
Si ton algo de hash est correct, tu vas en effet galérer à trouver une collision. Tu auras alors effectivement plutôt intérêt à faire une attaque par dictionnaire que par pure force brute, la probabilité que ton utilisateur ait un mot de passe faible étant bien plus grande (en pratique elle est même proche de 1…) que celle de trouver une collision sur SHA2, scrypt, PBKDF2 ou argon2…
Après, on trouve dans le commerce pour quelques centaines ou milliers d’euro des machines capables de calculer du SHA2 à plusieurs centaines de terra hash par seconde (Bitcoin s’est même spécialisé là dedans)… Ça prendra toujours quelques 262267361648628767629672630392222738306493224672122028428 d’années à collisionner un hash, mais on fait quand même des progrès spectaculaires en ce moment (les nombres commencent à pouvoir s’écrire sur une seule ligne :P).
Le
10/02/2017 à
15h
29
Faut peut-être arrêter de raconter n’importe quoi à un moment donné hein :)
Le sel est un paramètres qui doit nécessairement être en clair et stocké dans la db. Généralement il est même concaténé en tête du hash avant d’être stocké dans la base.
Il n’y a aucune limite haute à casser un hash, il suffit de trouver un mot de passe (pas forcément le véritable d’ailleurs) qui collisionne sur le même hash que celui indiqué dans la base. Il n’y aura même pas de candidat potentiel, vu que tu as la certitude de pouvoir t’authentifier avec à partir du moment où son hash correspond à celui en base de données.
S’il n’y a pas de sel, je ne me galère du coup même pas à faire une attaque par dictionnaire, mais je génère juste des tonnes de hash sur des tonnes de valeurs totalement aléatoires. En effet, comme ci-dessus, je m’en fous de trouver ton mot de passe, j’ai juste besoin d’en trouver un qui collisionne le hash de la base (il y a de très fortes probabilités que ça soit réellement le bon mot de passe, mais ce n’est pas garanti puisqu’un hash n’est pas bijectif mais uniquement surjectif). S’il y a un sel, je dois juste procéder utilisateur par utilisateur au lieu d’attaquer tous les hash en même temps.
Et si tu as choisis un mot de passe trop faible (et qu’il n’y a pas de sel), il y a même une chance non négligeable que le hash de ton mot de passe soit déjà connu (rainbow table) et donc que le casser prenne quelque chose comme 50ms.
En plus, ces calculs sont fait offline, donc toute parade anti-bruteforce mise en place par le site en question seront totalement inefficaces. Je bruteforcerais sur ma machine jusqu’à trouver une collision, et je m’authentifierais une seule et unique fois sur le site en question avec le mot de passe trouvé, qui validera obligatoirement l’accès au compte.
Bref, une base de données dans la nature mal hashée ou salée, c’est juste une véritable bombe à retardement et rien ni personne ne peut plus rien y faire. Le seul conseil qui vaille est d’alors changer immédiatement son mot de passe (ou de cesser d’utiliser le service jusqu’à ce qu’ils aient un hash suffisamment sécurisé), et de le changer aussi partout ailleurs où on l’avait utilisé.
On ne devrait jamais utiliser 2× le même mot de passe sur 2 services différents justement parce qu’en cas de fuite d’une base de données, les probabilités sont élevées que le service n’ait pas pris au sérieux la sécurité et ait stocké vos mots de passe au pire en clair au mieux hashé sans sel. Une fois le pass collisionné, soyez sûr qu’un attaquant ira tester le couple login/mot de passe obtenu sur tous les autres services qui lui passeront sous la main !
Le
10/02/2017 à
15h
05
C’est compliqué. Parce que justement, tu n’arrives pas à te connecter au serveur en face. Et que tu n’as strictement aucune idée de pourquoi ça merde…
Tout ce que ton navigateur sait, c’est qu’il n’a pas pu négocier avec le serveur en face. La raison réelle restera éternellement inconnue…
Le
10/02/2017 à
10h
23
Ça existe. Ça s’appelle NO_CYPHER_OVERLAP, mais faudrait juste améliorer la page d’erreur :P
Et d’ailleurs SSLLabs va bientôt changer leurs notations, et même les impôts vont virer au rouge à cause de 3DES qui n’est actuellement pas sanctionné.
Parce qu’il y a des gens qui ne veulent pas se sortir les doigts (on remets en perspective, Kp2 parle de changer de … navigateur) il faut accepter de rester a des normes de sécurité obsolètes ?!
A un moment donné, ce genre de comportements c’est juste inacceptable …
Surtout que ça met en danger tout le monde, y compris ceux avec des navigateurs plus ou moins à jour.
Parce que le serveur supporte des trucs pourris, je peux forcer les navigateurs à se rabattre sur ces trucs pourris alors que normalement ils auraient du utiliser quelque chose de plus fort.
Ou encore dans le cas de EBP, un de leur serveur supporte du SSLv2, je peux donc profiter de la faille DROWN même si votre navigateur ne supporte pas cette veille suite de chiffrement.
Dit autrement, si vous êtes sur le même réseau que moi (au pif au Starbuck du coin ou sur un wifi public), je peux plutôt « facilement » (c’est l’affaire de 2 ou 3 heures voire de quelques minutes pour les trucs les pires) avoir accès à vos cookies ou à votre mot de passe, et ainsi récupérer tous vos plans comptables ou les fiches de paies de tous vos employés. Même si votre navigateur Firefox est le plus à jour disponible…
Le
09/02/2017 à
17h
28
ZoZo a écrit :
Pour la taille, ça vient des administrateurs de base de données qui gardent leurs habitudes des années 80 et essayent d’économiser quelques octets par enregistrement dans une table.
Cela dit, les mots de passe (et tous les champs en fait) doivent quand même avoir une limite, sinon t’as des rigolos qui vont t’envoyer des mots de passe qui prennent plusieurs Mo à stocker, ça va vite s’accumuler.
Quant aux caractères interdits, parfois alors qu’ils sont dans les 128 premiers de la table ASCII et donc ne prenne pas plus de place en base, ça me laisse perplexe.
C’est justement totalement débile si tes mots de passe sont hachés.
Une fois passés à la moulinette d’un sha512, ils feront TOUS 512 bits et ne contiendront que des caractères hexadécimaux (0-9A-F).
Même si en entrée tu lui as mis l’intégral des 2To de ta collection de porn ou que ton mot de passe contient des
sinogrammes encodés en UTF-8…
C’est même pour ça que tu peux être sûr qu’un site qui limite la taille du mot de passe ou les caractères utilisables ne stocke pas de manière sûre ce mot de passe dans sa base de données. Et même très certainement en clair…
Le fait que le sel (la chaîne aléatoire en question) soit connue ne représente pas de risque. Par contre, en crypto, ne réinventez pas la roue, et suivez aveuglément les conseils des experts (Aeris, en l’occurrence, est une source sûre)
Pas trop aveuglément quand même :) L’intime compréhension, c’est toujours mieux :P
Le
09/02/2017 à
15h
49
Arrêtez de vous prendre la tête, tout est expliqué ici…
Je suis loin d’être expert, mais le problème c’est pas tout simplement les short-ID ?
C’est exactement ça. Les short-ID c’est le mal.
Et suite au mirroring plus profond de certaines clefs, c’est devenu doublement plus le mal :P
Le
22/08/2016 à
21h
19
KissFC a écrit :
Il n’y a pas bruteforce => tu reforge le certificat racine a la suite. Tu collisione pas toutes les clés, juste une suffit : comme dit au dessus tu reproduis ensuite le certificat racine.
Il n’y a justement PAS de certificat racine sous GPG. Et récupérer une clef compromise ne compromet pas l’ensemble de la chaîne.
Pour la faille de 2014, le problème est beaucoup plus complexe que tu ne le penses.
Les serveurs de clef ne supportent que les short ou long ID pour récupérer une clef.
Si tu demandais à télécharger une clef à partir de son empreinte complète (par exemple 0x6A68B76126297666 ECF48F03EFB74277ECE4E222), GPG faisait l’accès en réalité par le short ou long ID (selon ta configuration). Ici il réclamait donc la clef 0xEFB74277ECE4E222 ou 0xECE4E222.
Mais il ne vérifiait pas en retour que la clef téléchargée correspondait réellement à l’empreinte complète (cas d’une clef collisionnée).
Les seules personnes vulnérables étaient donc les personnes récupérants leurs clefs en spécifiant une empreinte complète ET qui n’avaient pas configuré leur GPG pour utiliser les long-ID (une collision sur le long-ID (64 bits) est improbable à l’heure actuelle) ET qui ne vérifiaient pas l’empreinte manuellement par la suite (toute signature devrait impliquer la vérification manuelle de l’empreinte complète).
Et en plus pour être exploitable, l’attaquant doit être en mesure de pouvoir intercepter les communications entre les 2 correspondants (et pas que d’un seul côté, sinon le récepteur recevra un message chiffré par la mauvaise clef, donc ne pourra pas le lire, donc détectera l’attaque).
Et même si tu récupérais une mauvaise clef, tout le reste de ton porte-feuille reste 100% safe puisqu’il n’y a pas de racine (l’intérêt de GPG par rapport à X.509/TLS).
Bref, certes c’est une erreur de GPG, mais ça n’était pas exploitable en pratique.
Le
22/08/2016 à
18h
55
edrin17 a écrit :
Question: À qui profite le crime la faille ?
Vu la débauche de moyens mis en œuvre c’est pas Jean-Paul dans sa cave de geek qui fait ça… " />
La question à 10 balles…
Surtout que cette faille est connue depuis 2011 et que toute personne faisant de la crypto a depuis longtemps désactivé les short-ID… Et donc seul un nœud-nœud pourrait se laisser berner.
Reste les logiciels mal configurés par défaut, qui pouvaient du coup récupérer la mauvaise clef auprès des serveurs de clef quand on précisait le short-ID (par exemple lors du rafraîchissement de la clef correcte).
Je me suis personnellement fait avoir sur ce cas-là.
Mais les fausses clefs étant et révoquées et non utilisables (elles ne permettent pas le chiffrement), elles n’étaient pas réellement dangereuses. Un proof-of-concept à taille réelle peut-être ?
Le
22/08/2016 à
18h
32
KissFC a écrit :
Rajoute aussi qu’il y a une volonté de recréer l’emprunte par captation de messages “legit” envoyés aux serveurs : le cassage du certif ne se fait pas par brute force mais par compilation de réponses.
La volonté n’étant pas plus de casser que d’avoir une emprunte valide durable dans le système.
Pour la puissance de calcul, elle est toute relative, ça fait un certain temps que les puces AMD sont devenues très bonnes pour faire ce genre d’opérations sha/ash + guess, restait qu’a monter un POC pour montrer que PGP était faillible de la sorte sur certaines configs.
Se qui m’étonne, c’est le nombre de bits nécessaires relativement faible pour reforger une clé valide, ça veux dire que derrière reforger une empreinte complète devient possible en relativement peu de temps. :/
Euh… E_TOO_MUCH_NO_SENSE
1- Je ne vois pas où il y a la moindre interception de message « legit »…
Il suffit d’utiliser un annuaire de clef pour trouver celle qu’on veut cibler, puis générer une collision de short-ID, puis itérer sur les signatures, etc
Et l’attaque est par bruteforce (il n’y a pas d’autre moyen de collisionner un ID de toute façon).
2- Les puces ont beau être effectivement très efficace pour faire du calcul de hash, aucune ne l’est pour générer rapidement des clefs RSA de 2048 bits comme celles collisionnées, qui est basé sur de la recherche de nombres premiers aléatoires (processus non accélérable, il faut bruteforcer pour trouver de tels nombres…).
Les meilleurs CPU ne génèrent que quelques centaines de clefs GPG par seconde.
3- Un short ID fait 8 octets hexadécimaux soit 20 bits de sécurité. Ça se casse donc en « seulement » 4 milliards de tentative. C’est ridiculement petit en terme de crypto (on conseille actuellement au moins 128 bits de sécurité).
Ramené à la centaine de clefs par seconde, ça donne quand même une 50aine de jour de calcul pour collisionner une clef…
Pour générer le faux graph de Torvald, ça a donc été l’équivalent d’années de calcul qu’il a fallu paralléliser massivement (donc avoir accès à des ressources importantes) pour arriver à collisionner autant.
Le
22/08/2016 à
17h
00
le podoclaste a écrit :
Je comprend pas trop la première faille. C’est davantage une faille d’un site qui collecte les clés publiques plutôt que de PGP lui-même, non ?
Non. Le problème vient que des personnes s’amusent à générer des clefs dont l’ID court sur 8 octets est le même.
Par exemple la vraie clef de Torvald est 0x79BE3E4300411886, et la fausse 0x6211AA3B00411886 (même short-ID 0x00411886).
Là où est la nouveauté, c’est qu’un attaquant s’amuse à générer un ensemble de fausses clefs et à recréer la chaîne de certifications des vraies clefs.
Par exemple, Torvald (0x79BE3E4300411886) est signé par Alan Cox (0x7EEBC095B516BAEF), et l’attaquant recrée cette chaîne avec un faux Torvald (0x6211AA3B00411886, même short-ID 0x00411886) signé par un faux Cox (0xD8C912C0B516BAEF, même short-ID 0xB516BAEF).
Et ceci sur des centaines de clefs reliées les unes aux autres.
Tu peux donc te faire doublement avoir maintenant :
si tu t’arrêtes sur la comparaison du short-ID
si tu vérifies en plus la chaîne de confiance
Bref, short-ID c’est cassé (depuis 2011) et on passe aux long-ID (16 octets) voire aux empreintes complètes (40 octets).
Cryptographiquement parlant, il n’y a donc rien de neuf. Mais là, ça montre une réelle volontée de nuire (mirrorer des centaines de signatures comme ça, ça demande une puissance de calcul relativement importante).
Le
22/08/2016 à
15h
14
J’ai ajouté des couleurs histoire de pouvoir distinguer les clefs collisionnées (même short-ID = même couleur (mais la réciproque est fausse :P))
Le
22/08/2016 à
14h
28
Oui, sinon tu passes à côté du vrai problème :P Le short-id tout seul est connu depuis des lustres.
Le
22/08/2016 à
13h
40
linconnu a écrit :
C’est le problème du libre ça. Comme le source est disponible les failles sont visibles facilement.
En gros c’est comme si une banque installait un super système de sécurité mais laissait les plans sur internet.
N’importe qui qui travaille dans la sécurité sait que le secret est primordial.
Donc il ne faut jamais utiliser du libre quand on veut faire de la sécurité à cause du manque de secret, ce qui s’applique à la vie réelle s’applique aussi à l’informatique.
Dans le monde privateur, cette faille n’aurait jamais été détectée, faute de relecteur/auditeur.
Et jamais publiée si elle l’avait quand même été.
Et sûrement jamais patchée si elle n’avait pas été publiée.
Ça n’aurait pas empéché les petits malins de s’en servir.
Les failles 0-days, c’est bien connu que ça n’existe pas…
D’un autre côté, rien ne t’empêche de monter plusieurs machines virtuelles (ou prochainement raspi/olimex/pine64), avec un Cozy pour chaque utilisateur. Techniquement, ça ne pose aucun soucis.
LXC me semble tout indiqué pour gérer ça, mais effectivement, ce n’est pas forcément à la portée du 1er venu et il faut maîtriser un peu la ligne de commande :P
C’est même presque l’idéal, le jour où tes mioches quittent le cocon familial (ou ton·a conjoint·e :P), tu leurs rends leurs données !
Le
10/06/2016 à
10h
51
> Que ca sorte ou non ,ca reviendrait presque à lier ton compte avec tel ou tel entreprise
Toute la stack étant libre, tu peux monter ton instance chez toi dans tous les cas.
Ou sortir de chez ton hébergeur quand tu le souhaites.
Le
10/06/2016 à
08h
45
C’est pour ça que Cozy te permet l’auto-hébergement, et bientôt de tourner sur Raspi et autres cartes équivalentes. Au pied de ton lit !
Le
10/06/2016 à
07h
59
Ça va même encore plus loin.
Rien ne sort du Cozy. Tout est calculé en local et EDF n’aura jamais accès aux données NEST par exemple.
Ça permet à EDF de fournir au propriétaire du Cozy des services qu’il n’aura pas pu avoir autrement.
100 commentaires
WannaCrypt : des nœuds Tor saisis par les autorités françaises
17/05/2017
Le 18/05/2017 à 15h 53
Ç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…
Le 18/05/2017 à 15h 18
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.
Le 18/05/2017 à 15h 11
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.
Le 18/05/2017 à 14h 31
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.
Le 18/05/2017 à 14h 28
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.
Le 18/05/2017 à 14h 08
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).
Le 18/05/2017 à 09h 54
> 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à…
Le 18/05/2017 à 08h 47
> 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).
Le 17/05/2017 à 19h 19
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).
Le 17/05/2017 à 18h 19
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).
Le 17/05/2017 à 17h 58
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.
Le 17/05/2017 à 17h 05
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.
Le 17/05/2017 à 16h 27
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.
Le 17/05/2017 à 16h 19
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.
Le 17/05/2017 à 16h 18
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.
Le 17/05/2017 à 16h 07
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.
Le 17/05/2017 à 15h 50
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 !
Le 17/05/2017 à 15h 15
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)
Le 17/05/2017 à 15h 01
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é)
Le 17/05/2017 à 14h 15
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).
Le 17/05/2017 à 14h 00
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).
Le 17/05/2017 à 13h 58
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).
Le 17/05/2017 à 13h 42
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.
Le 17/05/2017 à 13h 31
Les logs ? Quels logs ? Il n’y en a juste pas sur les relais Tor.
Mot de passe en clair dans un email, SSLv3 : EBP s’explique
09/02/2017
Le 10/02/2017 à 17h 38
Le 10/02/2017 à 17h 23
Le 10/02/2017 à 16h 21
Le 10/02/2017 à 15h 29
Faut peut-être arrêter de raconter n’importe quoi à un moment donné hein :)
Le sel est un paramètres qui doit nécessairement être en clair et stocké dans la db. Généralement il est même concaténé en tête du hash avant d’être stocké dans la base.
Il n’y a aucune limite haute à casser un hash, il suffit de trouver un mot de passe (pas forcément le véritable d’ailleurs) qui collisionne sur le même hash que celui indiqué dans la base. Il n’y aura même pas de candidat potentiel, vu que tu as la certitude de pouvoir t’authentifier avec à partir du moment où son hash correspond à celui en base de données.
S’il n’y a pas de sel, je ne me galère du coup même pas à faire une attaque par dictionnaire, mais je génère juste des tonnes de hash sur des tonnes de valeurs totalement aléatoires. En effet, comme ci-dessus, je m’en fous de trouver ton mot de passe, j’ai juste besoin d’en trouver un qui collisionne le hash de la base (il y a de très fortes probabilités que ça soit réellement le bon mot de passe, mais ce n’est pas garanti puisqu’un hash n’est pas bijectif mais uniquement surjectif). S’il y a un sel, je dois juste procéder utilisateur par utilisateur au lieu d’attaquer tous les hash en même temps.
Et si tu as choisis un mot de passe trop faible (et qu’il n’y a pas de sel), il y a même une chance non négligeable que le hash de ton mot de passe soit déjà connu (rainbow table) et donc que le casser prenne quelque chose comme 50ms.
En plus, ces calculs sont fait offline, donc toute parade anti-bruteforce mise en place par le site en question seront totalement inefficaces. Je bruteforcerais sur ma machine jusqu’à trouver une collision, et je m’authentifierais une seule et unique fois sur le site en question avec le mot de passe trouvé, qui validera obligatoirement l’accès au compte.
Bref, une base de données dans la nature mal hashée ou salée, c’est juste une véritable bombe à retardement et rien ni personne ne peut plus rien y faire. Le seul conseil qui vaille est d’alors changer immédiatement son mot de passe (ou de cesser d’utiliser le service jusqu’à ce qu’ils aient un hash suffisamment sécurisé), et de le changer aussi partout ailleurs où on l’avait utilisé.
On ne devrait jamais utiliser 2× le même mot de passe sur 2 services différents justement parce qu’en cas de fuite d’une base de données, les probabilités sont élevées que le service n’ait pas pris au sérieux la sécurité et ait stocké vos mots de passe au pire en clair au mieux hashé sans sel. Une fois le pass collisionné, soyez sûr qu’un attaquant ira tester le couple login/mot de passe obtenu sur tous les autres services qui lui passeront sous la main !
Le 10/02/2017 à 15h 05
C’est compliqué. Parce que justement, tu n’arrives pas à te connecter au serveur en face. Et que tu n’as strictement aucune idée de pourquoi ça merde…
Tout ce que ton navigateur sait, c’est qu’il n’a pas pu négocier avec le serveur en face. La raison réelle restera éternellement inconnue…
Le 10/02/2017 à 10h 23
Ça existe. Ça s’appelle NO_CYPHER_OVERLAP, mais faudrait juste améliorer la page d’erreur :P
https://null.badssl.com/
Pour le pourcentage, on parle de quelques pourcents maximum. À vu de pif je dirais même moins de 1%…Ça ne concerne globalement que IE8 sous XP…
Le 09/02/2017 à 21h 08
Ça sent une énorme faiblesse.
Déjà ça veut dire qu’ils stockent le mot de passe en clair.
Et qu’en plus de ça, ils font un test à la con en ajoutant lettre par lettre jusqu’à arriver à la fin ou à ce que ça passe…
À pleurer…
Le 09/02/2017 à 19h 11
Le 09/02/2017 à 17h 57
Le 09/02/2017 à 17h 28
Le 09/02/2017 à 16h 09
Le 09/02/2017 à 16h 05
Le 09/02/2017 à 15h 49
Arrêtez de vous prendre la tête, tout est expliqué ici…
https://blog.imirhil.fr/2015/10/27/stockage-mot-passe.html
PGP : des clés de signature mimées, GnuPG comble une faille vieille de 18 ans
22/08/2016
Le 23/08/2016 à 18h 33
Le 22/08/2016 à 21h 19
Le 22/08/2016 à 18h 55
Le 22/08/2016 à 18h 32
Le 22/08/2016 à 17h 00
Le 22/08/2016 à 15h 14
J’ai ajouté des couleurs histoire de pouvoir distinguer les clefs collisionnées (même short-ID = même couleur (mais la réciproque est fausse :P))
Le 22/08/2016 à 14h 28
Oui, sinon tu passes à côté du vrai problème :P Le short-id tout seul est connu depuis des lustres.
Le 22/08/2016 à 13h 40
Cozy Cloud lève quatre millions d’euros, pour s’ouvrir aux grands comptes
10/06/2016
Le 10/06/2016 à 20h 21
D’un autre côté, rien ne t’empêche de monter plusieurs machines virtuelles (ou prochainement raspi/olimex/pine64), avec un Cozy pour chaque utilisateur. Techniquement, ça ne pose aucun soucis.
LXC me semble tout indiqué pour gérer ça, mais effectivement, ce n’est pas forcément à la portée du 1er venu et il faut maîtriser un peu la ligne de commande :P
C’est même presque l’idéal, le jour où tes mioches quittent le cocon familial (ou ton·a conjoint·e :P), tu leurs rends leurs données !
Le 10/06/2016 à 10h 51
> Que ca sorte ou non ,ca reviendrait presque à lier ton compte avec tel ou tel entreprise
Toute la stack étant libre, tu peux monter ton instance chez toi dans tous les cas.
Ou sortir de chez ton hébergeur quand tu le souhaites.
Le 10/06/2016 à 08h 45
C’est pour ça que Cozy te permet l’auto-hébergement, et bientôt de tourner sur Raspi et autres cartes équivalentes. Au pied de ton lit !
Le 10/06/2016 à 07h 59
Ça va même encore plus loin.
Rien ne sort du Cozy. Tout est calculé en local et EDF n’aura jamais accès aux données NEST par exemple.
Ça permet à EDF de fournir au propriétaire du Cozy des services qu’il n’aura pas pu avoir autrement.
Let’s Encrypt utilisé par WordPress pour les sites hébergés avec un domaine personnalisé
12/04/2016
Le 12/04/2016 à 18h 52